Indexing mp3 gives 0 length

[jeena]

When I scan mp3 files then the length column in the audios table is always 0. You can try it with for example: https://www.jamendo.com/album/154762/feather-and-stone

I cloned the latest version from github and compiled it with:

./autogen.sh
make
sudo make install

And then I ran it with:

lightmediascannerd -S --directory=audio:/home/jeena/Music

Then I opened ~/.config/lightmediascannerd/db.sqlite3 with sqlite3 and run:

select length from audios;

That is where I only get as many 0 as I have mp3 files.

[barbieri]

those are likely "VBR" and we don't guess the size neither we compute the size, we'd only do that for "CBR", where the computation is simple.

Do you really need it? If so, do you consider using generic (ffmpeg/libavcodec)? Maybe it will provide you with the results.

[jeena]

I need it because I have an (HTTP) API where clients expect that information in listings of albums, tracks, playlists, etc. so they can show the duration before they got all the files. I am doing it right now manually (only for mp3's which have 0 as the duration in the database) every time they send a request as a workaround. But that is obviously sub optimal because I need to touch the files on every request which slows everything down quite a lot, when this information could be stored in the database.

What do you mean by generic? With a different process which updates the database or some plugin for LMS?

[barbieri]

Ah, I get what you mean.

LMS has the goal to scan as fast as possible and computing VBR length would impact. Actually most software I see out there just skip VBR and calculate on demand, when file is accessed the first time. I recall even iTunes did it.

What if you follow the same and cache the length you calculate, then in further requests it would be there. You still pay the same price, at a different point in time, and you can skip calculating for files that are never accessed. Would that work for you? Our tables are free to be modified from outside, you just need to take locking into consideration as SQLite is bad at that. For that we do offer a daemon and some synchronization primitives, but you can do something else on your side as well -- given you know your environment.

As for generic, it's a plugin based on ffmpeg/libavcodec. While our id3 is the "native" scanner that is optimized for our cases (scans only what we need). See https://github.com/profusion/lightmediascanner/tree/master/src/plugins/generic

[jeena]

Yes that would work quite ok I think. How would I chose the Generic plugin instead of the native one, would it be during compile time or during runtime? I guess there is no documentation about this? At least I wasn't able to find it yet. Same with documentation about the classes for the --directory argument, I found it in the code but it wasn't super obvious that in's called audio and not for example music.

[barbieri]

Depends on how you use it.

If you use LMS as a library, register plugins you want with lms_parser_add(lms, "generic"). That's what the test binary does, you must explicitly use -p/--parser.

If you use the daemon (from your description you may be here), then you can use -P/--parser (see its help).

Just be aware that if you use D-Bus activation it will execute the command as defined in org.lightmediascanner.service to be installed in your /usr/share/dbus-1/services or $HOME/.local/share/dbus-1/services (see README). This file is generated from https://github.com/profusion/lightmediascanner/blob/master/org.lightmediascanner.service.in, but you can modify it in your system or your packaging (RPM/DEB...) to include more parameters.

Last but not least, the daemon will automatically use all available plugins. So if you disable id3 and enable generic, the last one will be used. If you enable both, then id3 has higher priority (defined by the plugin itself, the "order" field of struct lms_plugin in lightmediascanner_plugin.h). This way you do not need to modify the org.lightmediascanner.service

As for documentation, only the daemon's help. It should be self-documented.

As for categories (ie: audio, picture and video), this is indeed not documented in the daemon. Ideally people will use LightMediaScanner as a library and also access the database directly, so the categories are the same as in the library and databases. I added the daemon as it was a common request and people were getting it wrong, so it is now provided.

BTW, it's nice to see more people are trying to use it. If you can share where you're using it and how did you find about LMS, I'd appreciate :-) I wrote this a long ago for Maemo (Nokia Internet Tablet OS), then it was used by some Asian people doing media boxes and more recently Tizen IVI folks (which originated the daemon request).

[jeena]

Thanks for the explanation, actually it didn't occur to me that this was supposed to be used as a library because it works so nice selfcontained with the daemon.

Ok cool then I think I get it how to use the generic with the daemon, will try it out tomorrow.

We used it in some projects at work (mostly proof of concepts and prototypes), we're also in the IVI domain, we even have a fork of it on our Github https://github.com/Pelagicore/Media-Manager-lightmediascanner-patched sadly not really is a upstreamable state.

But I'm writing an alternative Subsonic-server in Go because the original one is in Java and too heavy for my Raspberry Pi. I'm making the HTTP-API compatible so I can still use their clients.

LMS seemed a nice fit for something which will run on a Raspberry Pi, that way I don't need to reinvent the wheel and can concentrate on just the API part. This is my project: https://github.com/jeena/sonicmonkey but I just started like a week ago and it's my first project in Go.

[barbieri]

Sorry about the delay to reply.

LMS was a library in order to avoid complex interactions and overhead. For instance, if you have a single application using it, it's much more efficient to use it from a thread than to do via a DBus daemon and cope with the overhead to do simple things like get the progress.

Then, I guess after you get it working it would be a nice addition to write bindings in Go for it. Keep the LMS in its own thread, communicate via pipe(2) and expose it via Go-like primitives such as channels.