[SOLVED] Track shorter than 100ms

Running Mopidy 2 on ubuntu mate of a raspberry pi 2

Music files on a remote NAS, play fine on mpg123

I am seeing large numbers of mp3 files not being processed by mopidy scan.

I see this has been a regular occurrence historically, but as far as I can tell it was expected fixed in gstreamer 1.7.91

but I am on 1.8.2 so assuming that should have the fixes?

gst-discover shows zero duration, but gst-play-1.0 plays it fine.

gst-discoverer-1.0 /media/comb/wopr1/MusicOld/ACDC/1975\ -\ High\ Voltage\ (Australian)/ACDC\ -\ High\ Voltage\ (Australian)\ -\ 06\ -\ You\ Ain’t\ Got\ A\ Hold\ On\ Me.mp3
Analyzing file:///media/comb/wopr1/MusicOld/ACDC/1975%20-%20High%20Voltage%20(Australian)/ACDC%20-%20High%20Voltage%20(Australian)%20-%2006%20-%20You%20Ain’t%20Got%20A%20Hold%20On%20Me.mp3
Done discovering file:///media/comb/wopr1/MusicOld/ACDC/1975%20-%20High%20Voltage%20(Australian)/ACDC%20-%20High%20Voltage%20(Australian)%20-%2006%20-%20You%20Ain’t%20Got%20A%20Hold%20On%20Me.mp3

Topology:
unknown: ID3 tag
audio: MPEG-1 Layer 3 (MP3)

Properties:
Duration: 0:00:00.000000000
Seekable: yes
Tags:
datetime: 1975
album: High Voltage (Australian)
track number: 6
title: You Ain’t Got A Hold On Me
private-data: buffer of 16 bytes
publisher: Epic
album artist: AC/DC
genre: Rock
artist: AC/DC
container format: ID3 tag
replaygain track gain: -7.4400000000000004
replaygain track peak: 1.1081110000000001
has crc: false
channel mode: stereo
audio codec: MPEG-1 Layer 3 (MP3)
nominal bitrate: 192000
bitrate: 191712

I also cannot process wma, but thought I would work though this issue before trying to resolve that one.

Executable: /usr/bin/mopidy
Platform: Linux-4.1.19-v7±armv7l-with-Ubuntu-16.04-xenial
Python: CPython 2.7.12 from /usr/lib/python2.7
Mopidy: 2.0.0 from /usr/lib/python2.7/dist-packages
Mopidy-WebSettings: 0.1.4.2 from /usr/local/lib/python2.7/dist-packages
Jinja2>=2.7: 2.8 from /usr/local/lib/python2.7/dist-packages
MarkupSafe: 0.23 from /usr/local/lib/python2.7/dist-packages
ConfigObj>=4.0.0: 5.0.6 from /usr/lib/python2.7/dist-packages
six: 1.10.0 from /usr/lib/python2.7/dist-packages
Mopidy>=0.19: 2.0.0 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
setuptools: 20.7.0 from /usr/lib/python2.7/dist-packages
Mopidy-Moped: 0.6.4 from /usr/local/lib/python2.7/dist-packages
Mopidy>=1.0.0: 2.0.0 from /usr/lib/python2.7/dist-packages
setuptools: 20.7.0 from /usr/lib/python2.7/dist-packages
GStreamer: 1.8.2.0 from /usr/lib/python2.7/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.20.0
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
id3demux
id3v2mux
lamemp3enc
mad
mpegaudioparse
mpg123audiodec
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
flump3dec

I think I have the wma issue addressed with

sudo apt-get install gstreamer1.0-libav

ughh, putting wma back in breaks something, the scan dies with the following which looks like an attempt at a very bad allocation.

(python:8548): GLib-ERROR **: /build/glib2.0-NyxCB6/glib2.0-2.48.1/./glib/gmem.c:100: failed to allocate 3634425503 bytes

Looks like I can isolate the specifgic file that causes the out of memory.

I got it down to the folder last night.

If I can isolate that then I will raise a bug ticket.

That still leaves me with zero length mp3 track problem.

I have isolated to one music file that causes the out of memory problem, I will raise a ticket.

Still have the 100ms problem. Will try moving those files local instead of on the NAS and see what happens.

Meanwhile upgrading mopidy to 2.0.1 resolved the <100 ms track issue

As per apt.mopidy.com