Subject: File last modified?

Author: nollidj, 2005-11-10 07:08:19
What is your opinion on including functionality in the core to be able to query the last modified date of a lamipSongInfo? Not all of them would have a value for this, but I am thinking of a scenario like this:

-Control plugin caches metadata of files between sessions to avoid long loads on startup.
-On startup, plugin only checks "last modified" of files to see if they need updating. It uses cached metadata if it can.

A control plugin should probably not be trying to parse file URLs to see if it is a local file, a network stream, etc, and then checking the last-modified date... so is it a good idea to include functionality in the core to keep track of the last time a file associated with a lamipSongInfo* is updated?

It would be desirable to update the last-modified date if the file is modified at any point when lamip is running, of course, but this would probably not be feasible. What are your thoughts?


Author: nollidj, 2005-11-10 08:38:46
Now in looking at the code some more, I see all the new work on lamipURL... and I am thinking more about if it would be possible to do this. At what point should the last modification associated with a lamipSonginfo be checked? I am not so certain...

Author: ciberfred, 2005-11-10 18:53:17
i'm currently modify the url handling with songinformations... Ideas will be to have a database backend that could load/modified songinformations via external system (like by the control plugin). Well it could better to add something that we could name by 'a component' (another library) that add to lamip-core the hability to manage songs via a database like xmms2 or bmpx or mpd (if i have correct).

The next challenge will be to manage a very large number of song that an user could have on his system (like i begining having).

As i'm a stage of 'thinking/trying' your ideas will be welcome !

Author: nollidj, 2005-11-10 20:34:43
Sounds good!

Two questions:
1) If it has a built-in song library, how will lamip handle different encodings of metadata fields?
2) Is it planned to make a database backend part of lamip's core? Wouldn't it be better as an adjunct library that dumps its libraries into include/lamip/<library name>/ so that people can write different backends and there isn't a single one that might not do everything that a plugin writer would need?

Author: ciberfred, 2005-11-11 13:00:35
1) metadatas fields are row datas, so it will depend of the UI part to handle different encodings
2)if you could explain me a little more how you view this... with pictures, api examples, etc... don't forget that this feature should be enable or not by users at compil time ! all should be optionnal

Author: nollidj, 2005-11-11 19:20:46
1) With regards to field encoding, I am asking because if the library is expected to do any sorting or searching, it should know how to handle 16-bit characters or other strange encodings (especially for Asian charactersets). This seems better handled outside of the lamip core and in a library that can use glib or some other library for handling different encodings.
2) I will try posting something in the Wiki this weekend.

Author: nollidj, 2005-11-13 05:33:15
Please check in the Wiki to see some thoughts on metadata handling and plugin chaining.

The more I look at XMMS2, the more it looks like it and lamip are doing the same thing. What will be the differences between lamip and XMMS2?

Author: ciberfred, 2005-11-13 11:53:54
ok now that i have readed your text, let me explain futher.

It's right that in the past we have talked about howto handle streams/files/playlists/cdroms/etc...

First we have created the playlist structure to handle a list of files to be played. That's the most logical and first idea when you devel a player.
Second to handle multiple format of reading i have added the lamipURL structure, to be able to read a file like a http/ftp/what ever stream. both must have (i think) structure that we should keep.

The songinformation struture was added to be able to manage metadatas of an url, and for moment yes it's not well managed to handle metadatas from url streams. specialy for ogg/vorbis streams. (but the stream reading part need some more job from me that's why i setup it experimental in the configure script)
This structure was also added to be able to show in the UI the list of files in the playlist. Because when an user select an URL that is a .pls file for example. he just know this url not what there is inside (it's the job of the playlist plugin to fill theses informations). The songinfo is here to help the UI part to read/decode/show files that are into the playlist. Note that the mime-type is not a songinfo but an url identification (like the extention of the file). theses are put into the lamipURL struct instead of the songinformation.

So now that we know this the big problem is : what to do when i choose a playlist that is on a web-server and this playlist contain a list of urls that are playlists... How to help the UI dev to show this 'big' list of urls ? merging songinfo and subtraks to something like a treeview ? we could do this but it's not so... user friendly. and howto select the appropriate path ? like gtk+ do ? ("0:12:100" ?).

The last part is howto update songinformation when the URL is readed and encontrer a metadata. So the event thread was created to send informations to the UI/control part so that could be update the apropriate part of the UI.

After this, the problem of the playlist plugin. Yeah i really don't like this plugin because it need to call a function that is internaly in the core to select the good plugin to play the url. But when you think of the playlist plugin it's his job to select the apropriate plugin to play an url.

The next big job will be to slip inputs into 2 kind of plugins reader. containers/reader and readers/decoders. So the problem will be from one buffer size (the raw datas, without metadatas) to read/split, send to the decoder raw encoded datas, decode and send it to the output plugin correctly. wow the most ard job will be to do on the ogg and mp4 plugin. And this part i think will transform inputs in something like that xmms2 has done. That's why you think that lamip is a kind of xmms2.

But as i read mpd will do same things.. in fact the problem of all current audio players are the same and there are no more than one or two solutions to resolv this problem of container.
1- do like mplayer (all in a bundle binary) - much simple
2- do like xmm2 (all in separate plugins) - much harder

the same things is also for client/server communication use Dbus like or a proprietary/internal communication system.

Your ideas are good... just need an API to manage it :)

so time for lunch.. can't write more.

Author: ciberfred, 2006-06-29 08:59:58
well nollidj, the chaining plugin system is up in the core now (1 july 2006) and should work (also need tests).
So we handle without changing the coding style of the input plugin containers and formats for audio \o/
A wav file that contain mp3 datas for example could be readed by lamip. this also imply that ogg container will be handle more correctly also with matroska files too !

It's not really a 'chainning' plugin system like the xform system of xmms2. but it solve how to read most (all?) audio in a plugin system


Name : Email :