Longer tracks get cut short (mostly) - pianobar in termux on an android tv box - 32bit

[PhilT001]

I have pianobar running in termux on an android tv box (32bit) and I have noticed that longer tracks (5 minutes or more) are quite often cut short (95% of the time)

pianobar (2022.04.01)
ffmpeg version 6.1.1

config:

user = XXXX                                                                                                                                                           
password = XXXX                                                                                                                                                                       
autostart_station = XXXX                                                                                                                                                        
                                                                                                                                                                                             
act_songlove = +                                                                                                                                                                             
act_songban = -                                                                                                                                                                              
act_stationaddmusic = a                                                                                                                                                                      
act_songnext = n                                                                                                                                                                             
act_quit = q                                                                                                                                                                                                                                                                                                                                                      
                                                                                                                                                                                             
gain_mul = 1.0

Output from debug mode:

ao play signalled it needs more data health 6 minHealth 5
decoding buffer filled health 6 minHealth 5
ao play signalled it needs more data health 6 minHealth 5
av_read_frame failed with code -5, sending NULL frame
decoder is done, waiting for ao player
ao player got EOF, exiting
ao player is done
|>  "I'd Love to Change the World (2017 Remaster)" by "Ten Years After" on "A Space in Time" <3

I have Kodi running on the same device with the Pandoki plugin and this doesn't have the same issue (if that info helps)

[PromyLOPh]

I’m assuming errno -5 is EIO on your platform as well? errno -l should give you a list. Can you try increasing the setting buffer_seconds to some unreasonably high number and see if the problem persists?

[PhilT001]

errno-5 is = #define EIO 5

I've tried the buffer from 60 up to 180 (currently on 180) It seems less of an issue but I have just had a track with a length of 15:04 just stop with 7:07 minutes left.

[PromyLOPh]

Try higher values, like 1000 or more. My guess is that Pandora or some box between you and Pandora is dropping the connection early. pianobar does not download the entire song, but streams it while it plays, only downloading and decoding as much as fits in the buffer.

[PhilT001]

I've had the buffer set to 1000 for a number of days now and I haven't noticed any drops on long tracks, though I don't get to use pianobar as much during the week as I do at the weekend.

[PhilT001]

So this seems to work, but of course the trade off is long gaps between tracks (whilst the buffer is filled) Is it possible to start playback before the buffer is filled?
I'm still confused as to why short tracks (less than 5 minutes) don't seem to have this issue.

[PromyLOPh]

The audio files are not big (a few megabytes), so I assume your internet is not particularly fast? It’s not possible to start playback before the buffer is filled, because it causes stuttering on slow connections (which is exactly what the buffer is supposed to prevent). As I already wrote, my guess would be that something between you and Pandora is dropping long-living (i.e. for the duration of a song) connections. You could try to investigate via wireshark (or similar programs) and check if something resets your TCP connection. If none of that solves the issue you can also apply the following patch, which treats EIO as a retryable error, but I’m hesitant to apply it globally, because I don’t know which conditions (temporary vs. permanent) can trigger this error code. diff --git a/src/player.c b/src/player.c index 753d490..b0f15d5 100644 --- a/src/player.c +++ b/src/player.c @@ -541,7 +541,8 @@ void *BarPlayerThread (void *data) { BarPlayerSetVolume (player); const int ret = play (player); retry = (ret == AVERROR_INVALIDDATA || - ret == -ECONNRESET) && + ret == -ECONNRESET || + ret == -EIO) && !player->interrupted; } else { /* filter missing or audio device busy */