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

Scanner hangs with AVI file #726

Closed
xezpeleta opened this Issue Apr 29, 2014 · 12 comments

Comments

4 participants
@xezpeleta

xezpeleta commented Apr 29, 2014

Hi,

If you run mopidy local scan command and you have any AVI file in your media directory, the process will hang with no error message.

Therefore, it would be interesting to include .avi/.AVI files in default exclude section (mopidy.conf).

Thanks!

@jodal jodal added Audio labels May 12, 2014

@jodal jodal added this to the v0.20 - Audio and mixer cleanup milestone Jun 22, 2014

@marmeladema

This comment has been minimized.

marmeladema commented Jul 14, 2014

I noticed a similar behaviour for tiff image on Mopidy 0.18.3
For me, it was actually a gstreamer problem.
The method set_state (called in the _reset method in scan.py) can be blocking, it depens on the filetype there is in the pipeline.
I agree it could be interesting to add .tif / .tiff to the excluded_file_extensions directive.
However i see limitations to this approach:
1/ extension can be wrong
2/ It can still occur for other filetype

Could it be possible to add some kind of timeout to the set_state call ?
There is already this kind of check in the _collect method.

@adamcik

This comment has been minimized.

Member

adamcik commented Jul 14, 2014

Could you perhaps reproduce with media dir pointing at just the tiff / a directory with just it and GST_DEBUG=4 GST_DEBUG_FILE=./gstreamer.log mopidy local scan and pastebin the gstreamer.log file (not directly in the bug please as the file will be rather large)?

@marmeladema

This comment has been minimized.

marmeladema commented Jul 14, 2014

Here is the log from gstreamer:
https://drive.google.com/file/d/0B8K0JZ9aOLshSDkwaHpvME0zOXM/edit?usp=sharing
And here is the log from modipy:
https://drive.google.com/file/d/0B8K0JZ9aOLshaldzX0FZaFozWWM/edit?usp=sharing

By the way, i had to kill mopidy with -9 since it did not respond at all.

@adamcik

This comment has been minimized.

Member

adamcik commented Jul 14, 2014

Hmm, not sure what is happening quite yet and wasn't able to reproduce. Will follow up when I know more or have something more I want tested.

@adamcik

This comment has been minimized.

Member

adamcik commented Jul 14, 2014

On a quick hunch, try moving self._bus.set_flushing(True) (https://github.com/mopidy/mopidy/blob/develop/mopidy/audio/scan.py#L116) to after self._pipe.set_state(gst.STATE_NULL) - worth a quick try any way.

@marmeladema

This comment has been minimized.

marmeladema commented Jul 15, 2014

I will to that as soon as i can :)

@adamcik

This comment has been minimized.

Member

adamcik commented Jul 15, 2014

Correct, the hunch is that the set state needs messages which are being flushed to complete and deadlocks.

@marmeladema

This comment has been minimized.

marmeladema commented Jul 16, 2014

It does notre change anything ... Maybe it's related to the fact that scanning expire after 1000ms ? The gstreamer sink might be in a wrong state or something

@marmeladema

This comment has been minimized.

marmeladema commented Sep 22, 2014

Any news ?

@adamcik adamcik modified the milestones: v0.21 - Audio cleanup part 2, v0.20 - Audio cleanup part 1 Dec 28, 2014

@adamcik

This comment has been minimized.

Member

adamcik commented Apr 9, 2015

Think I finally ran into something similar enough to maybe have found a fix for this. In my case GStreamer for some reason decided a valid MP3 might be a h264 file. And for added fun the the h264 parser then went into and endless loop trying to handle the MP3 data... There is of course a GStreamer bug for part the endless loop part already, but against 0.10 which is no longer maintained.

On the bright side I decided to try and just reject video/* during decoding, and it makes us skip the bad parses and move on to identifying my test file as an actual MP3 and the scan is progressing.

I'll try and get a PR in with the minor change needed. And with some luck this also resolves this issue.

@adamcik adamcik self-assigned this Apr 9, 2015

@adamcik

This comment has been minimized.

Member

adamcik commented Apr 10, 2015

My previous comment was actually for my attempt at fixing what turned out to be an other instance of #797. But this got me testing the scanner on a larger corpus, and I've just made the scanner handle videos just fine. So there will be a PR fixing this shortly :-)

@adamcik

This comment has been minimized.

Member

adamcik commented Apr 12, 2015

I think #1124 fixed this. Closing this now, and if I'm wrong feel free to reopen.

@adamcik adamcik closed this Apr 12, 2015

@jodal jodal modified the milestones: v1.0.x, v1.3 - Audio cleanup 2 Apr 13, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment