Hello
I know that there are a few topic on this subject.
When ever I launch a scan, the same list of tracks return a similar error to below
WARNING Failed local:track:Roy_Ayers/Ubiquity/04_Love.mp3: Timeout after 1000ms
I have looked through all the affected mp3 and I cannot see anything in the metadata that is consistent in the all the files. I can play the files fine in IRIS or moped when I drill down to them manually.
So I was wondering if anyone can tell me what the mopidy scan, scans for? Is it worth re-encoding the files (I have about a hundred error files), if the error comes from that?
Any thoughts are most welcome
I’m not sure what it is exactly that Gstreamer 1.14 doesn’t like about these files but you can see the same issue with their metadata tool: gst-discoverer-1.0 (install with sudo apt-get install gstreamer1.0-plugins-base-apps). The point being that it’s not really something we can do much about in Mopidy itself.
Whatever the bug is, it’s fixed in GStreamer v1.16 but unfortunately that’s not available for Debian stretch. I’m not sure we can do anything to actually fix it. However, as you can say, these files may be perfectly playable and Mopidy-File is happy to let you play them but you’ll notice they won’t show a duration whilst playing. Mopidy-Local filters out files with less than 100ms audio content but as a workaround for this bug we could expose that as a config setting. I’m not really sure why it filters out short files, perhaps the Scanner was previously less robust to ignoring non-audio files.
Thank you so much for explaining so clearly the issue.
The file that are failing are no shorter than the others, so maybe this is a formatting issue that gstreamer does not like. I will reencode some of the files and so if that solves it.
If the issue will go away in up coming debian releases, then from my point of view, I would not lose any sleep on this. It sounds like a bug that has to be lived with.
I’d be very keen to hear if re-encoding the troublesome files helps. The problem with waiting for the next Debian release is that it’ll be nearly 2 years from now.
I fixed the file I was looking at with:
ffmpeg -i BAD.mp3 -acodec copy FIXED.mp3
I batch transcoded some error files from mp3 to flac and back to mp3 on the PI using soundconverter.
https://soundconverter.org/
And these files no longer showed up as errors.
So that is a reasonable work around.
That said, the files are not showing up in the local list following the mopidy scan. But I suppose that is another issue.
Thanks for explaining how it works to neophyte like me.
I have just reencoded some mp3s directly to new mp3s, without passing via a flac file, and these new mp3 files continue to have errors in the scan. So my only solution is to round trip the file with a flac version.
Did you use the command I posted above or something else? I guess it’s not a big deal to go via flac.
I’m not comfortable with command line. I use the soundconverter app
Sadly, your ffmpeg command line does not work for me, so a flac roundtrip it will have to be.
After roundtripping lots of files, sadly I have to admit that this method does not resolve the issue completely. I still have some file that fail on scans and I cannot see any reason why.