Skip to content

AAC: Track shorter than 100ms #935

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

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

AAC: Track shorter than 100ms #935

PythonSmith opened this issue Jan 14, 2015 · 20 comments

Comments

@PythonSmith
Copy link

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
Copy link
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
Copy link
Author

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
Copy link
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
Copy link
Author

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

@adamcik
Copy link
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.

@melvinvdb
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

@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
Copy link

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
Copy link

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

@ecoCuyo
Copy link

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
Copy link
Contributor

@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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

@kingosticks
Copy link
Member

@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
Labels
None yet
Projects
None yet
Development

No branches or pull requests