pianobar stops after 1-3 seconds of first song and process hangs

[RevCivic]

Pianobar will start, log in, and begin playing a song, but instantly cuts out. I have tried reinstalling many times. The time for the song does not change at all in the course of it playing the song (maybe 1-3 seconds at most). It almost seems as when it attempts to update something it breaks. I am able to see the menu items by pressing "?" for a few moments (not sure exact time) but that will also crash as soon as I attempt to use "q" to quit. I have had to manually kill the process to close pianobar. I have done various amounts of reboots, updates, upgrades, rpi-updates. I am not sure what files would be most helpful to share, but please let me know and I will be happy to provide.

Your environment

Pianobar Ver. 2018.06.22-dev Raspbian Stretch Kernel 4.14.94-v7+ ffmpeg version N-92238-gb7b3e8c5c7 Copyright (c) 2000-2018 the FFmpeg developers built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516 configuration: libavutil 56. 19.101 / 56. 19.101 libavcodec 58. 33.102 / 58. 33.102 libavformat 58. 19.101 / 58. 19.101 libavdevice 58. 4.105 / 58. 4.105 libavfilter 7. 37.100 / 7. 37.100 libswscale 5. 2.100 / 5. 2.100 libswresample 3. 2.100 / 3. 2.100

user = *@****.com password = * audio_quality = high

Steps to reproduce

run make, make config file, run "pianobar"

Expected behaviour

pianobar should play full songs

Actual behaviour

No errors, process seems to hang up, song stops playing after 1-3 seconds, time remaining/total time is never updated, "q" does not work to quit the program.

[edward-p]

Will you be able to press "s" to reselect a station?

[RevCivic]

Below is the terminal output. the song still stopped after about 2 seconds, but I was able to use these commands until I attempted to use "q", then nothing worked. I will leave it locked (not killing the process) for now and if you have any ideas on information that could be helpful I will attempt to retrieve them.

Welcome to pianobar (2018.06.22-dev)! Press ? for a list of commands.
(i) Login... Ok.
(i) Get stations... Ok.
|>  Station "Chillstep Radio" (4175841504356829895)
(i) Receiving new playlist... Ok.
|>  "Bodyache" by "Purity Ring" on "Another Eternity"
         0) q S Chillstep Radio
         1)  Q  QuickMix
[?] Select station: 1
         0) q S Chillstep Radio
         1)  Q  QuickMix
[?] Select station: 0
        +    love song
        -    ban song
        a    add music to station
        c    create new station
        d    delete station
        e    explain why this song is played
        g    add genre station
        h    song history
        i    print information about song/station
        j    add shared station
        n    next song
        p    pause/resume playback
        q    quit
        r    rename station
        s    change station
        t    tired (ban song for 1 month)
        u    upcoming songs
        x    select quickmix stations
        b    bookmark song/artist
        (    decrease volume
        )    increase volume
        =    delete seeds/feedback
        v    create new station from song or artist
        P    resume playback
        S    pause playback
        ^    reset volume
        !    change settings
         0) q S Chillstep Radio
         1)  Q  QuickMix
[?] Select station: 0
(i) Receiving explanation... Ok.
(i) We're playing this track because it features r&b influences, a knack for catchy hooks, beats made for dancing, a thin female vocal performance, a laid back female vocal, a breathy female vocal, romantic lyrics, the use of chordal patterning, use of tonal harmonies, inventive synth arrangements, subtle use of pianos, light synth fx, ambient synth textures, trippy soundscapes, prevalent use of groove and and many other similarities identified in the Music Genome Project.
|>  Station "Chillstep Radio" (4175841504356829895)
|>  "Bodyache" by "Purity Ring" on "Another Eternity"
|>  Station "Chillstep Radio" (4175841504356829895)
|>  "Bodyache" by "Purity Ring" on "Another Eternity"
#   -02:53/02:53

[PromyLOPh]

Have a look at issue #672 – it seems to be quite similar. The quintessence is: Disable compiler optimizations when building (-O0). Also, please test if the master branch exhibits this behavior as well.

[vandys]

Happens here on trunk, with -O0 or -O2 no diff. Interestingly, it was working, then I went premium and it stopped working. I changed config to quality low and it went back to working (though with reduced audio quality, of course). So it's a problem ticked by the high quality audio rate.

[PromyLOPh]

That is weird. Can you check out the branch debug, compile it, run PIANOBAR_DEBUG=1 ./pianobar and post the last 30/40 lines here?

[vandys]

I had to remove NDEBUG from the Makefile, too. Here's the output. debug.txt

[PromyLOPh]

Did you set buffer_seconds to zero in your config file? (minHealth is zero) Can you try different values (5, 10, 1000, 10000, …)?

[vandys]

No, no config entry for buffer_seconds. I set it to 100 and it plays for about that many seconds before stopping. The time counter does not change during all of that; it sticks at the initial (track length) time value. I'm wondering if the fact that minHealth is 64 bits is messing with the debug output, rather than telling the true story. I'll look into that and post more if I find anything.

[vandys]

Yup, those were 64-bit long long's, fixed the format. So here's a new debug log. debug.txt

[PromyLOPh]

Guess I should be using PRIxx macros when printing integer values, oops.

So, to get this right: Debug output continues even after audio output stopped and there’s no message saying “ao player is waiting for more frames …” right before the music stops playing (example: https://github.com/PromyLOPh/pianobar/issues/672#issuecomment-453180460)?

What OS/machine are you running pianobar on, @vandys?

[vandys]

I apologize, let me include the complete debug log of a hang, which does indeed end with:

ao player is waiting for more frames after code -11 (Resource temporarily unavailable)

and the (never counting down) time marker.

This is 686 Linux (Mint 19).

debug.txt

[RevCivic]

I just got back to looking into this, I did recompile, same issues, however, setting the audio quality to low did seem to resolve the issue as a temporary solution. Going to test it for a while to see if any errors spring up.

[PromyLOPh]

I pushed fixes into the branch fixes-678. Please give it a try. Apparently this is not a threading issue as I thought initially. I’ve simply been using the wrong time_base to calculate timestamps, which never was an issue with AAC/MP4.

[vandys]

Nice! Fixes the problem here.

[PromyLOPh]

Release 2019.02.14 fixes this issue.