MythMusic hangs after FFmpeg merge #686
Comments
kmdewaal
added
version:master
|
Hi Klaas: I don't use MythMusic a lot, mainly because the in-play controls have seemed not to give the results I expected; but maybe I misunderstood. Highlighting the FF ikon and repeatedly pressing Enter doesn't skip forward cleanly. But with my settings I'm not getting hangups. F36/master. Mostly, for audio, I select track and player from the file manager. They are mainly mp2 with an .mp3 file extension. |
|
@paul-h yes it is the seek that gives the problem. Starting playback from the start is OK but then manually skipping forward (5 seconds in my system) also causes a hang. I did some more testing today after @Jpilk reported it works OK for him. My main music collection is on a NAS and is mounted on the MythTV box with NFS. I have had this setup, with the NAS storing the music and the videos, for many years and it has always worked OK. BUT... Today I did test with a smaller music collection stored on a local hard drive and this plays OK, both for seek when resuming playback and for skipping forward. |
|
I seeing this since upgrading to v33 as well -- things hang at the end of a track instead of progressing to the next track. The "resume mode" doesn't seem to make any difference in my case. But perhaps most interestingly my music is also on NFS. |
|
I captured some stack traces while mbe was wedged in this state (bt.log). I guess the interesting threads might be:
Maybe there is something broken with polling on an NFS fd either generally or specifically in Qt's use? |
|
I still haven't reproduced a hangup in either 32/fixes or master, but I ought to clarify my comment of 29 Dec. Stepping forward during playback is fine for single steps, but multiple steps in quick succession confuse the ringbuffer, and playback continues with short out-of-order segments. Usually it eventually recovers. Since most of my 'songs' are much longer than 3 minutes this makes seeking tedious and I usually use smplayer or mpv. Single steps give FE log messages like "avfdecoder.o: seek time 6273", where the number is in seconds from start-of-file and the usual increment is 5s. Holding down the spacebar for some time gives "AOBase: Buffer is full, AddData returning false" followed by tens of seconds of choppy repetitive playback, eventually becoming ok. I suspect that a 'lock until buffer update is complete' might help... I haven't noticed any difference in this between local storage and NAS using cifs, but obviously the time to complete is likely to be different in each case. HTH, John |
|
With The first is from https://github.com/MythTV/mythtv/blob/master/mythplugins/mythmusic/mythmusic/avfdecoder.cpp#L453 and if I attach gdb to my hung mfe then I get: Full logs: mfe-bt.txt This corresponds to: Looking at another call in mythtv/libs/libmythtv/decoders/avformatdecoder.cpp I see: I wonder if that I can't see that anything changed on the ffmpeg side wrt the arguments to av_seek_frame though so not sure why it would regress, maybe I'm barking up completely the wrong tree... Could this be at all related to the issues with videochannels which have a static graphic (low or zero framerate) which had various problems at one point (something to do with audio vs video as the time base?)? A music stream is superficially a bit similar to that case perhaps? |
|
With debug symbols for libavcodec: It seems that https://stackoverflow.com/questions/17765667/flac-seeking-with-ffmpeg seems similar but is nearly a decade old so I think probably not relevant |
|
Thanks for the tracebacks and the analysis. It is not a trivial problem. What has changed is the FFmpeg version and the process of gluing MythTV and FFmpeg has been done with great enthusiasm but with little respect for the code... |
|
Lots of testing today showed that my idea about the problem being related to music stored on NFS is not correct. |
|
The problem is caused by how the end-of-file is handled. In MythMusic the decoding is done by FFmpeg but the file I/O is done by MythTV. The version of FFmpeg that is in fixes/32 still has temporary code that converts a read value of 0 bytes into an EOF status. This starts at line 522 of FFmpeg/libavformat/aviobuf.c and is repeated here for convenience: This workaround has been declared obsolete in 2017 and it is now removed from the FFmpeg in fixes/33 and master. This file is used only by MythMusic so there is no risk for regressions in the rest of MythTV. There are two side issues that might need looking at. However, that is for another day. |
Great find!
I've applied it to my v33 based system in the living room and it seems to have solved the issue AFAICT. FWIW I think it looks like the right fix. |
Detect end-of-file when reading music files and return the AVERROR_EOF status to FFmpeg. In version 33 MythTV has upgraded to a version of FFmpeg that does require this. Refs #686
|
Thanks to all and especially to @ijc for helping to solve this issue. Fix is applied to master and fixes/33 so this ticket can now be closed. |
MythMusic hangs after starting to play music; it does not respond to key presses anymore and it the only way to stop it is to do a double Control-C. This happens when going from one track to the next or when MythMusic starts playing somewhere in a track.
This problem appeared after the latest FFmpeg merge.
Platform: Ubuntu 22.04.1, Fedora 37
MythTV version: v33-Pre
Package version: Built from source
Component: MythMusic
What steps will reproduce the bug?
Start mythfrontend
Select "Listen to Music"
This starts MythMusic playing music from the current playlist, in the current track.
When the track is played starting from the beginning it plays OK.
When the track starts playing from another position, e.g. somewhere in the middle, it hangs.
Terminate mythfrontend by doing a double Control-C or a "kill -9" from another terminal.
Start mythfrontend.
Select "Listen to Music"
This starts MythMusic playing music from the current playlist at the beginning of the current track.
This plays OK; let it play for e.g. 10 seconds.
Stop MythMusic by pressing Escape and do "Exit and stop playing music".
Select "Listen to Music"
This starts MythMusic playing music from the current playlist, in the current track at the last position, e.g. at 10 seconds.
This now again hangs forever.
How often does it reproduce? Is there a required condition?
100% reproducible.
It is possible that it depends on a configuration item; in my case MythMusic is configured to always continues where it was left, i.e. it starts to play from the current playlist, the current track at the last played position.
What is the expected behaviour?
Playing music from the last played position. It is like this in v32 and in v33-Pre before the FFmpeg merge.
What do you see instead?
Mythfrontend/MythMusic hangs.
Additional information
As MythMusic is OK in v32 and it fails in the current master (v33-Pre) I did a bisect and this ended here:
[klaas@modu mythtv]$ git bisect good
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
163f468
71c34d7
ff32a77
67a442e
d8b7d3d
54902b0
a44bcfb
ad29e1c
c8bef3c
2cfd14e
422fbc8
40a04d5
e546928
71e2219
a1868de
753a94c
We cannot bisect more!
This set of commits is the commit that updates FFmpeg and all the commits to the MythTV sources that are needed to make it compile again. It is not possible to bisect further.
The correct behavior when playing back music is that at intervals a block of data is read and played etc.
In v32 that looks like this:
This is from lines 1027-1038 in file mf-20221227-1835-music-ok-v32.log (attached).
This is the same sequence in v33-Pre and here the last log line is repeated forever while the GUI hangs:
This is from lines 1011-1022 in file mf-20221227-1835-music-fail.log (attached).
I did have a look at the commits that make up the FFmeg merge but I did not see anything obviously wrong.
This is the log file for v33-Pre where MythMusic fails:
mf-20221227-1835-music-fail.log
And this is the log file for v32 where MythMusic plays OK:
mf-20221227-1835-music-ok-v32.log
The text was updated successfully, but these errors were encountered: