From: bulleid@ku.gro.lioff
In message <10dfs4k$2j983$1@dont-email.me>, Chris Elvidge
writes
>On 24/10/2025 at 13:18, Adrian wrote:
>> In message <10dei3u$27uve$7@dont-email.me>, Lawrence
>> =?iso-8859-13?q?D=FFOliveiro?= writes
>>> On Thu, 23 Oct 2025 19:09:02 +0100, Adrian wrote:
>>>
>>>> If I do a cut and paste of the aplay command, it works fine. So the
>>>> problem looks as though it is some thing to do with the python call.
>>>
>>> I would try to confirm this by running the Python script (or at least
>>> a copy of the part that does the aplay command) from a terminal
>>> session. In other words, try to minimize all the differences between
>>> the situation where you can successfully invoke the command, and the
>>> one where you can’t.
>>>
>> Thanks for the detailed reply.
>> I've just tried that, and running the Python interactively works (I
>>get sound). So far, so good.
>> In the normal way of things, the Python code is started by cron
>>using @reboot. Being aware that the environment that cron gets can be
>>different to that of an interactive session, I've just killed off the
>>background Python code, and restarted it using nohup (which I think
>>should give the same environment as the command line). That still
>>fails (code runs, no sound), but now the error message doesn't appear,
>>instead in the error file, I get the message :
>> nohup: ignoring input and appending output to 'nohup.out'
>> which it doesn't, that file remains empty.
>> So it looks as though the problem is with the Python code running in
>>the background, rather than the Python code itself. I'm wondering if
>>one of the updates that has run since the previous reboot (~8 weeks
>>ago) has come into play because of yesterday's reboot.
>> I forgot to mention that the path to the sound file is absolute,
>>rather than $HOME/...
>> When I run Python from the command line, it tells me that I'm
>>running Python 3.11.2
>>
>>>> Both command line and python are running under the same user.
>>>
>>> I suspect there is some issue with setup of environment variables
>>> (e.g. $HOME) when running the script in the background versus
>>> interactively.
>> I would agree, but see above. And why did it work pre-reboot ?
>>
>>>
>>>> What I'm seeing logged by the python code is the following error :
>>>>
>>>> ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
>>>> aplay: main:831 audio open error: Unknown error 524
>>>>
>>>> I've tried rebooting again, and an Internet search doesn't come up
>>>> with anything for my particular problem (they all seem to be
>>>> "nothing working").
>>>
>>> I did a search for “alsa Unknown error 524” and found this
>>> >> open-audio-device-unknown-error-524-what-is-going>
>>> where the error was fixed by putting something into the systemwide
>>> ALSA config.
>>>
>>> This would be consistent with my suspicion that the per-user setup
>>> for your background versus interactive cases is not exactly the same.
>> Thanks. I tried adding those entries, but it makes no difference.
>> And to repeat, the background and foreground sessions are run by the
>>same user, so I think the problem is "how it is being run" rather than
>>"who is running it".
>> Adrian
>
Thanks.
>Check your XDG_RUNTIME_DIR and/or PULSE_COOKIE settings. I had to set
>theses to get vlc to play properly from a task set from a non-terminal
>run file though a bluetooth speaker.
>HIH
The first comes back as :
/run/user/1000
and the second isn't set.
However, the speakers are wired in, rather than Bluetooth, which may or
may not be relevant.
Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
