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
mopidy local scan fails: "stack smashing detected" on "unknown data: 'datetime'" #1323
Comments
I srubbed all my music using the beets scrub plugin, but then I noticed something after some experimentation: it always fails on Here are the
|
Can you provide a file it crashes on? If you don't want to upload it somewhere public, you can for example email me at stein.magnus@jodal.no. |
I've received the file it crashes on, but haven't looked further into this yet. |
I have the same issue and here it crashes on a mp3 file. This is the file (password: 2772) |
I can reproduce this issue with @thomastoye's file on develop and I can successfully scan it using the feature/gst1 branch, which will be included in Mopidy 1.2. |
GStreamer 0.10 itself crashes with @thomastoye's file:
In other words, I don't think there's anything Mopidy can do to work around this crash with GStreamer 0.10. Our solution will be to upgrade to GStreamer 1.x which fixes the crash:
|
GStreamer 1.x support was merged with PR #1419. Considering this fixed by it. |
I added a lot of new music to my library recently, and when I wanted to import them with
mopidy local scan
,mopidy
failed.mopidy &
works perfectly as a music server, it's just importing that doesn't work. I deleted the~/.local/share/mopidy/local/library.json.gz
file, but I still got the same error. Here's what it looks like (mopidy -vv local scan
):Note the
DEBUG 2015-10-31 17:47:50,271 [12004:MainThread] mopidy.audio.utils Ignoring unknown data: 'datetime' = <GstDateTime at 0x7f5c6c0a4d70>
just before*** stack smashing detected ***: /usr/bin/python terminated
: it seems that some of my audio files have a propertydatetime
thatmopidy
can't handle, whatever that means.The audio files were processed with
beets
(for tagging), but it seems rare:mopidy
processed 700 tracks before it failed for the first time. I triedmopidy local scan --limit 100
until I encountered the stack smashing, then it occurred every time, on the same file.The text was updated successfully, but these errors were encountered: