Mopidy: AAC: Track shorter than 100ms

[PythonSmith]

When scanning my library by "mopidy local scan" it finds my new songs; but it says "Track shorter than 100ms":
xxx.aac: Track shorter than 100ms

Codec read with VLC:
http://prntscr.com/5shbu8

I'm using a banana pi with mopidy branch: develop

[adamcik]

Could you try gst-discoverer-0.10 /path/to/file/... and paste the result. It wouldn't surprise me if GStreamer indeed thinks this is a short track and its likely fixed in never GStreamer versions.

The whole min length of tracks things is in reality a workaround for an other problem we had.

We should probably make this a setting so that people at least have a way to workaround this.

[PythonSmith]

Done discovering file:///media/hdd/mopidy/media/2015/The%20Fray%20-%20How%20To%20Save%20A%20Life%20(Jiggers%20Remix).aac

Topology:
audio: MPEG-4 AAC
audio: MPEG-4 AAC

Properties:
Duration: 0:03:18.117030919
Seekable: yes
Tags:
audio codec: MPEG-4 AAC

[adamcik]

Weird, and this was with gst-discoverer-0.10 and not gst-discoverer-1.0? Part of me is temped just to say wait for us switching to GStreamer 1.0 and hope that it helps, though that isn't very helpful for getting to the bottom of the issue.

[PythonSmith]

Sorry can't tell anymore, now always running music always via android
I remember that I had very bad environment

[adamcik]

We've updated the scanner to start playing the file if there isn't a duration after the pre-roll. This should very likely fix this issue, if the switch to GStreamer 1.x didn't already. Closing this now, please reopen if it is still an issue.

[melvinvdb]

I have this problem, running latest jessie build on my rpi. Tried mopidy 2.0 release and development branch. Every mp3 shows "Track shorter than 100ms" when executing sudo mopidyctl local scan.

I don't have gst-discoverer-1.0. ls /usr/bin/gst* shows
/usr/bin/gst-inspect-1.0 /usr/bin/gst-launch-1.0 /usr/bin/gst-typefind-1.0

[melvinvdb]

Seems that removing
elif result.duration < MIN_DURATION_MS: logger.warning('Failed %s: Track shorter than %dms', uri, MIN_DURATION_MS)
from local/commands.py solves the problem.

[alafanechere]

I encounter the same issue for MP3 files.
I run the last Mopidy version I installed from raspbian packet manager.
I also use mopidy-local-sqlite.

WARNING  Failed local:track:04%20Son%20Of%20Tribe.mp3: Track shorter than 100ms

Then I cannot see these files on my local files listing.

[zaphbbrox]

Seems that removing
elif result.duration < MIN_DURATION_MS: logger.warning('Failed %s: Track shorter than %dms', uri, MIN_DURATION_MS)
from local/commands.py solves the problem.

@melvinvdb I think it just removes the information from the log.
I managed to add songs with this problem by commenting out all lines where mtime appears, but I'm not sure this is a good solution.

[Joolee]

Also running in to this bug, coincidentally?, also on an rpi2

Some MP3's do get indexed, some don't. I have tried comparing working vs non working files but can't find any common differences between the sets. I have looked at encoder, filesize, id3/ape format, bitrate and sample rate.

When I run gst-discoverer-1.0 --timeout=100 /path-to-media/*.mp3 | grep Duration multiple times, the results change between runs! Almost all runs have songs with duration 0, for some specific songs, the correct time is rarely displayed. Other songs are rarely without a correct duration and there are also runs where all songs get detected correctly.

My library resides on a samba share but copying a small subset to local disk (sdcard) doesn't change the results.

When I test with gst-discover-0.10, results are always correct for all files. Except on some occasions the last files in the directory throw this error:
(gst-discoverer-0.10:26552): GStreamer-CRITICAL **: gst_value_init_and_copy: assertion 'G_IS_VALUE (src)' failed

The value of result.duration in local/commands.py#L145 is "None" for the failing files. The failing files change every time I run 'local scan' but some files are almost always failing.

Some debug information:
debug.txt
debugruns.txt

[SeeSpotRun]

@Joolee, @zaphbbrox @PythonSmith: if you have a chance, could you please test using https://github.com/SeeSpotRun/mopidy/tree/fix/gstreamer_not_pushing_tags_2 to see if this fixes the problem? This branch has a workaround in mopidy/audio/scan.py to address an upstream bug in gstreamer.

Alternatively if you are feeling adventurous you could try compiling gstreamer from git source...

[glennpierce]

I tried the branch gstreamer_not_pushing_tags_2 and it now works for me.
Note this was on a raspberry pi 2

Thanks

[zaphbbrox]

@SeeSpotRun didn't have time yet, but I'm going to test it the next few days.

[ecoCuyo]

Honey, there is hope :-) ... I also ran into this problem after upgrading the OS of a working mopidy installation from wheezy to jessie.
How exactly would I use/employ the branch gstreamer_not_pushing_tags_2 to make the error go away?

Any feedback is highly appreciated!

[SeeSpotRun]

@ecoCuyo you can just copy the one changed file as per https://github.com/mopidy/mopidy/issues/1474#issuecomment-199428453

Maybe check first that your current mopidy version is 2.0

[ecoCuyo]

Great, it works - thx!

Am 03.04.2016 um 14:53 schrieb Daniel T [email protected]:

@ecoCuyo you can just copy the one changed file as per #1474 (comment)

Maybe check first that your current mopidy version is 2.0

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[SteveCrowBro]

I also had this problem on my RPi3 and didn't find a clear concise fix. For anyone else stuck in this situation, I managed to resolve it by running sudo apt-get install gstreamer0.10W
My setup is as follows:
Remote media mounted under /mnt/media
Local configuration pointing to /mnt/media/audio

[CarlvO]

Still got this issue on a fresh install of Jessie on a Raspberri Pi B. I have installed mopidy via the mopidy repo. No idea what gstreamer0.10w is, since I cannot find that package and moreover mopidy uses gstreamer1.0 as far as I can tell. Spotify plays without problems. I am still confused: is this a gstreamer or a mopidy issue?

[SteveCrowBro]

Sorry, I think the W is a typo in my previous post

[kingosticks]

@CarlvO you are correct that mopidy 2.0 uses only gstreamer1.0. Installing gstreamer 0.10 packages may help with older versions of mopidy, but they won't help with mopidy 2.0 problems.