[Request]Foo_quicktag + sqlite.dll Options

[jkwarras]

Hi,

After having installed the mod foo_playcount by kode54 that uses sqlite.dll to store the playcount information, so no tagging your file, I wonder if someone (musicmusic?) would be interested in implementing the same feature for foo_quicktag. This way the users that want to use it to rate their songs but want this information to be kept outside of their file itself, will have the choice. In the same time, such a implementation will make other tags written by quiktag also out of the file, so at the end, it depends what you want this component to do (really tag the file, or just a database).

[Killmaster]

Just out of curiousity, how do I get this sqlite thing to work? It doesn't seem to do anything... is there something that I have to set up somewhere or something?

[Killmaster]

Hmm.. maybe this plugin could be expanded into a more general database component, called foo_sql perhaps? There could be a general framework in place so that other plugins could be modified to use the external database accordingly. OTOMH, foo_skip, foo_quicktag, foo_playcount, are all plugins where having an external db makes sense.

Just a few things that could stand to be added to a foo_sql dealie..

-list of everything in the db - each file path and whatever tags have been associated with it, option to delete/modify certain entries, etc.
-option to merge tag data with db data, configurable with TAGZ
-Automatic notification for missing files - if I move a file outside of Foobar, I'd like to retain the db data associated with it. Maybe an option to search your HD/a certain folder for missing files? This feature's kinda important to me, I'd hate to lose everything because I had to move something outside of Foobar.

[eliazu]

1. why do people dont like to save info in the file tag?
2. the sql saves other tags as artist, album, etc. ? could it be useful to other things too? like generated playlist?

[Killmaster]

1. why do people dont like to save info in the file tag?
2. the sql saves other tags as artist, album, etc. ? could it be useful to other things too? like generated playlist?

1. Some people like to keep their files unchanged, primarily when file sharing. Otherwise, the data will change, resulting in a different hash and requiring people to regenerate any sfvs (or have people stratching their heads as to why the files are getting shared seperately from the rest of the network) Additionally, since ratings are subjective and playcounts vary from user to user, it doesn't make sense to keep this data in the file when it is transferred to another user.

2. Foobar already has an internal database for the storage of data, which does exactly what you're talking about. The problem here is that some of us want to modify the actual tags, but keep certain tags from getting added to the file, which is currently impossible.

[jkwarras]

Hmm.. maybe this plugin could be expanded into a more general database component, called foo_sql perhaps? There could be a general framework in place so that other plugins could be modified to use the external database accordingly. OTOMH, foo_skip, foo_quicktag, foo_playcount, are all plugins where having an external db makes sense.

That's an excellent idea, hope someone will be interested. Don't know how difficult could it be to make it

[jkwarras]

Hmm.. maybe this plugin could be expanded into a more general database component, called foo_sql perhaps?

Sorry to bump this thread but I find this idea quite interesting and really nice for having out of your files personal info while keeping the ability to use tagging fb2k functions. One of the issues that fb2k brings me is the fact that I can't just use the 'block updates operations' in my files, because if I ever wants to tag my files in fb2k (mainly using masstagger, which is very powerful and I can't find something similar out of fb2k) then I have to unblock and my files will also be tagged with any already 'blocked' tags.

I think that having the possiblity of writing (as mod playcount does) to a sql database is really a good solution, the sqlitle approach is really as simple as copying two dll files into your PC and that's it. From a user point of view is simple, fast and it works without problems.

I don't have the impression that someone is really interesting in implementing this (i.e. foo_quicktag using the same sqlitle approach, or the foo_sql proposed idea), but let's see if I can give some arguments to make someone a little more interested :

- It'll store in a external DB personal fields like %rating%, and you could also make use of other custom fields like (just an example) %favourite%.

- It'll make possible to different people using the same PC under different accounts to rate their music differently.

- It'll not make your files change everytime you rate it (which I believe it's a personal taste that shouldn't stick to the file itself).

- It'll reduce problems about duplicates (or even more) songs using fb2k and external players like the ipod. Not a problem for a 256mb key, but for a 20 GB of music it's really hard to keep track of duplicate songs.

I would like to hear critics, comments, etc...

[beto]

I second this request. Maybe the external database (sql or whatever) support/SDK could be considered as a foobar2000 core change/addition to the next version(s), I mean for storing usage related info and plugin development.

I'm just speaking my mind out and please bear with me if I said anything stupid/unfeasible...

[hunted]

I second this request. Maybe the external database (sql or whatever) support/SDK could be considered as a foobar2000 core change/addition to the next version(s), I mean for storing usage related info and plugin development.

I'm just speaking my mind out and please bear with me if I said anything stupid/unfeasible...

Did peter say "absolutly not" to database filtering, so that user specific tag info isnt stored in the file and only in the database? This seems to me like the most sensable solution.

This post has been edited by hunted: Mar 11 2005, 23:05

[jkwarras]

Did peter say "absolutly not" to database filtering, so that user specific tag info isnt stored in the file and only in the database?  This seems to me like the most sensable solution.

It desn't seems that kind of features (separate DB and file tags info) is going to be implemented anytime soon, at least I've never seen any fb2k developper talk about that in this forum (if it has been I've missed it and I'll appretiate if someone can post links). So I only see as a solution if someone would like to implement an external database plugin (even a simple one) based in SQL or whatever and let the user the choice of what to store in it.

[Fermion]

I did some coding (and copy pasting kode54's code ) this weekend and I noticed that it was a bad idea trying to do it with SQLite. AFAIK it doesn't support adding new columns to existing database table, so either you have to use a set of predefined tags, or regenerate the table everytime a new kind of tag is added. Well, at least I have a perfect quicktagger for my own needs, because there are only couple of fields I need it for. I think I'll try again soon with MySQL.

[jkwarras]

Well, at least I have a perfect quicktagger for my own needs, because there are only couple of fields I need it for.

Could you make it available? I mean, i'll only use it for playcounts, rating and maybe a favourite tag. If this can be done with your mod version then I'll interested in this kind of compoentn (and I'm sure many people around here as well)

[jsheridan]

I did some coding (and copy pasting kode54's code  ) this weekend and I noticed that it was a bad idea trying to do it with SQLite. AFAIK it doesn't support adding new columns to existing database table, so either you have to use a set of predefined tags, or regenerate the table everytime a new kind of tag is added. Well, at least I have a perfect quicktagger for my own needs, because there are only couple of fields I need it for. I think I'll try again soon with MySQL.

Easy to solve with a bit of creative thinking...

Use a table like: "fileurl","fieldname","value"

[Fermion]

Use a table like: "fileurl","fieldname","value"

That's brilliant! And I'm an idiot.. but I have to say that I have only 2 days of experience with databases. I'll try that as soon as I have time.

jkwarras: I'll think about it. Still needs work.

[jkwarras]

jkwarras: I'll think about it. Still needs work.

Ok. But do you have plans to make it available if it becomes stable and usuable?

[Fermion]

Ok here it is. But this version is meant only for testing! I would appreciate if you could check that all the features below are working properly. I'd recommend taking backups before experimenting. There are some parts of kode54's code that are hard for me to understand, and I'm not yet very familiar with foobar API, so there may be bugs. Any feedback is welcome.

Download
No longer available, check here
Features
- Uses external SQLite database to save the applied tags. (quicktag.db in foobar directory). You can use a database analyzer tool or something to check the contents. For example SQLite Analyzer
- The tags in audio files are not modified.
- Tags are shown in tech info, and can be accessed in tagz-scripts using two underscores like "__RATING" etc.
- Also the tags from ext. database are reloaded when foobar reloads tags from files.
- When a file is removed from foobar database, the entries in external database are also removed.
- When a file is moved (trough foobar), the entries in the external database are modified to the new file name.
- Has all the same functionality as the original quicktag plugin.
Installation
Copy foo_quicktag_sqlite.dll to foobar2000\components\ directory and sqlite.dll to foobar2000\ directory.
Thanks to
Musicmusic (foo_quicktag), kode54 (sql functionality in foo_playcount), thoehrer (foo_playcount)

This post has been edited by Fermion: Mar 15 2005, 22:33

[beto]

Excellent. thanks a lot for this. I'll try it as soon as I get home.

in the future could you please consider supporting MySQL? For me it would be much more manageable, but thanks anyway.

[jkwarras]

Ok here it is. But this version is meant only for testing! I would appreciate if you could check that all the features below are working properly.

Thanks you for this! I'll try asap and report any problems.

Damn, I'm so happy... finally, DB only personal info tags...

[anza]

Cool, I really need to test this one. Thanks!

edit: I just did a "%rating% to %__rating%" conversion with this plugin for 5128 tracks so I'm ready for some real testing now. It sure took some time converting those tags..

This post has been edited by anza: Mar 15 2005, 00:20

[beto]

i've been trying it and so far so good!!

This post has been edited by beto: Mar 15 2005, 02:03

[Aero]

Ok here it is. But this version is meant only for testing! I would appreciate if you could check that all the features below are working properly. I'd recommend taking backups before experimenting. There are some parts of kode54's code that are hard for me to understand, and I'm not yet very familiar with foobar API, so there may be bugs. Any feedback is welcome.

I haven't tried your component yet, but one thing that kode54's component missed was an implementation for metadb_callback::on_info_edited(). This prevents outside component from modifying the metadata and having it stored to the database.

The particular component I'm thinking of is my foo_pod. Certain people (hi jkwarras!) have been asking for a way to sync up the iPod's rating with something that work with Foobar. So what will happen is when the iPod's playlist is loaded into Foobar, foo_pod will extract the rating from the iPod and find the corresponding song in Foobar and set the rating metadata. Without metadb_callback::on_info_edited(), your component won't notice that foo_pod has set the rating.

[Fermion]

I haven't tried your component yet, but one thing that kode54's component missed was an implementation for metadb_callback::on_info_edited().  This prevents outside component from modifying the metadata and having it stored to the database.

The particular component I'm thinking of  is my foo_pod.  Certain people (hi jkwarras!) have been asking for a way to sync up the iPod's rating with something that work with Foobar.  So what will happen is when the iPod's playlist is loaded into Foobar, foo_pod will extract the rating from the iPod and find the corresponding song in Foobar and set the rating metadata.  Without metadb_callback::on_info_edited(), your component won't notice that foo_pod has set the rating.

So would it be a good solution for example to have a user defined list of the tags to be updated to the external database automatically in on_info_edited()? And after that what should be done with the metadata values in foobar database, delete them or just let them be? Because there's not very much point in having an external database, if the same data is also in the foobar database or in the files. Or is it possible for foo_pod to set the values straight to the tech info?

[Fermion]

Fixed version is here. Please remove the test version and the old database file (quicktag.db).

[dsuliman]

Great plugin. Thanks!

Is that possibility to add "resync" button as in modified foo_playcount? I notice that if I copy my foobar or clean my database, I can't retrieve the information that is stored in quicktab.db. It will be handy to have "resync" button as in foo_playcount which I can have all my information back.

[jkwarras]

So far everythign works fine for me. I've trasnfered all my %rating% to %__rating%

I have some requests, if you could have the time to take alook at them I'll appretiate:

1) Could it be possible to allow lower-case, I mean instead of %__RATING%, to have %__rating%. I know it's not a big deal, but it's just that I don't like having these values in caps in the tech info properties page, but I can live with it

2) Could you add the possibility of using system date and hour values as playcount mod? I mean, having the possiblity of using i.e. %Y-%m-%d %H:%M:%S (that will show up as 2005-03-16 10:22:10). In my case I would like that to use system info to create a %__added% field (added to database info). But it could be used for other things.

3) A nice feature would be to allow to add more than one field at a time. i.e. when you press on Quick tag SQL>Rate 5 will fill the two fields %__rating% and %__rating_date%.


In anycase, thanks you very much because your plugin is really useful