Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Program quit after 3-4 hours #6

peppi001 opened this Issue Jun 23, 2014 · 4 comments


None yet
3 participants
Copy link

peppi001 commented Jun 23, 2014


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.


This comment has been minimized.

Copy link

danielmoore123 commented Oct 22, 2014

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?


This comment has been minimized.

Copy link

undertuga commented May 2, 2015

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?



This comment has been minimized.

Copy link

danielmoore123 commented Feb 27, 2016

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: #49 (comment)

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: #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....


This comment has been minimized.

Copy link

danielmoore123 commented Feb 28, 2016

#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.