-
Notifications
You must be signed in to change notification settings - Fork 695
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
Comments
Could you try 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. |
Done discovering file:///media/hdd/mopidy/media/2015/The%20Fray%20-%20How%20To%20Save%20A%20Life%20(Jiggers%20Remix).aac Topology: Properties: |
Weird, and this was with |
Sorry can't tell anymore, now always running music always via android |
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. |
I have this problem, running latest jessie build on my rpi. Tried mopidy 2.0 release and development branch. Every mp3 shows " I don't have |
Seems that removing |
I encounter the same issue for MP3 files.
Then I cannot see these files on my local files listing. |
@melvinvdb I think it just removes the information from the log. |
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 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: 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: |
@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... |
I tried the branch gstreamer_not_pushing_tags_2 and it now works for me. Thanks |
@SeeSpotRun didn't have time yet, but I'm going to test it the next few days. |
Honey, there is hope :-) ... I also ran into this problem after upgrading the OS of a working mopidy installation from wheezy to jessie. Any feedback is highly appreciated! |
@ecoCuyo you can just copy the one changed file as per #1474 (comment) Maybe check first that your current mopidy version is 2.0 |
Great, it works - thx!
|
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 |
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? |
Sorry, I think the W is a typo in my previous post |
@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. |
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
The text was updated successfully, but these errors were encountered: