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

AAC: Track shorter than 100ms #935

Closed
PythonSmith opened this Issue Jan 14, 2015 · 20 comments

Comments

@PythonSmith

PythonSmith commented Jan 14, 2015

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

This comment has been minimized.

Member

adamcik commented Jan 14, 2015

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

This comment has been minimized.

PythonSmith commented Jan 15, 2015

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

This comment has been minimized.

Member

adamcik commented Apr 5, 2015

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

This comment has been minimized.

PythonSmith commented Apr 6, 2015

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

@adamcik

This comment has been minimized.

Member

adamcik commented Feb 15, 2016

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.

@adamcik adamcik closed this Feb 15, 2016

@melvinvdb

This comment has been minimized.

melvinvdb commented Feb 20, 2016

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

This comment has been minimized.

melvinvdb commented Feb 20, 2016

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

This comment has been minimized.

alafanechere commented Feb 23, 2016

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

This comment has been minimized.

zaphbbrox commented Feb 29, 2016

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

This comment has been minimized.

Joolee commented Mar 12, 2016

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

This comment has been minimized.

Contributor

SeeSpotRun commented Mar 19, 2016

@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

This comment has been minimized.

glennpierce commented Mar 20, 2016

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

This comment has been minimized.

zaphbbrox commented Mar 20, 2016

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

@ecoCuyo

This comment has been minimized.

ecoCuyo commented Apr 1, 2016

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

This comment has been minimized.

Contributor

SeeSpotRun commented Apr 3, 2016

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

Maybe check first that your current mopidy version is 2.0

@ecoCuyo

This comment has been minimized.

ecoCuyo commented Apr 4, 2016

Great, it works - thx!

Am 03.04.2016 um 14:53 schrieb Daniel T notifications@github.com:

@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

This comment has been minimized.

SteveCrowBro commented Jul 16, 2016

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

This comment has been minimized.

CarlvO commented Jul 29, 2016

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

This comment has been minimized.

SteveCrowBro commented Jul 29, 2016

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

@kingosticks

This comment has been minimized.

Member

kingosticks commented Jul 30, 2016

@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.

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