search

ChristopheJacquet / PiFmRds

FM-RDS transmitter using the Raspberry Pi's PWM
GNU General Public License v3.0
1.44k stars 331 forks source link

Program quit after 3-4 hours #6

Open peppi001 opened 10 years ago

peppi001 commented 10 years ago

Hi!

I use PiFmRds with piping audio. My command is: mpg123 --loop -1 --buffer 1024 --no-icy-meta -s http://streamURL:8000 | sox -t raw -b 16 -e signed -c 2 -r 44100 - -t wav - equalizer 11800 0.7q 20 | sudo ./pi_fm_rds -freq 92.5 -audio - Everything works perfectly for 3-4 hours, then the program quit with this message: "Could not rewind in audio file, terminating" I tested it with mp3 stream and local mp3 too, and the result is the same.

If You have free time, please test it. Thanks. Peppi

danielmoore123 commented 10 years ago

I have exactly the same issue on all mono/stereo icecast streams, is there no function we can insert so it automatically picks itself up again if it falls?

undertuga commented 9 years ago

Exactly the same issue here! Running the following command on a Raspberry Pi (1) Model B (rev2) board, while transmitting some shoutcast stream through sox piping (OS: Raspbian 'wheezy' & 'jessie'):

sox -t mp3 http://[stream.url]:8000 -t wav - | sudo ./pi_fm_rds -freq 96.0 -pi FFFF -ps PIRDS -rt 'PI RDS DEMO' -ctl pifm -audio -

Any hint on the reason for this to happen, and also, on how to possibly fix this, other than writing some script that 'reboots' pifmrds when it falls?

Thanks! undertuga

danielmoore123 commented 8 years ago

I resolved the "Cannot Rewind Terminating" bit.... Not sure on it's exact cause but it seems to be related to the internet (even on the LAN too for some reason) dropping out even just a smudge (or slowing down) and after so many hours it just decides to eventually give up on the stream, similar concept I suppose to how if you start 2 streams at once on a PC they will eventually come out of sync the longer you leave them running despite starting them at the same time.... What makes me think it's network is those theories plus how the problem never occurs when piping in via a USB device as I have provided code for here: https://github.com/ChristopheJacquet/PiFmRds/issues/49#issuecomment-178892636

My issue is now, the termination is still a clean one.No error, just clean, I have had an overrun one a few times but think that is just memory on the Pi itself.

I too am seeking something that restarts the code again to allow it to continue unsupervised, for example, when the code stops, simply hit the up arrow on your keyboard followed by enter and it will re-run fluently.

There is a fix here: https://github.com/ChristopheJacquet/PiFmRds/issues/16 but I tried it with the modifications and now the program won't even start.

I have been assured that the program is not coded to quit so really not sure why it does this and really not sure why it can't pick itself up again....

danielmoore123 commented 8 years ago

16 looks to have fixed it. It still fails but this fix by @btweb gets the program to pick itself up again when it does die. Give it a try.

smithjacobj commented 3 years ago

I stumbled on this via Google. Is there a known upstream issue with mpg123 or is it maybe the server cutting off connections to make sure dead streams aren't resumed? Thankfully the script I'm using for my project (github.com/smithjacobj/dementia-radio) automatically restarts the stream, so it's a minor inconvenience, but it's still not the perfection I want.

I may look into the issue in greater depth later.

EDIT:

[240:11] Decoding of kexp128.mp3 finished.
[jacobjms@jacobjms-fedora-PC1EVN4B ~]$ $?
bash: 0: command not found...