foo_custominfo, New component for "database-only tags". Options

[Teukka]

i have a weird problem. I'm trying to rate songs but it works only one playlist...when i choose another playlist and trying to rate songs...nothing happens. someone help me

Probably you have "library only" checked and the files in the second playlist are not in the library.

where exactly i can uncheck this "library only"?

[fabiospark]

i have a weird problem. I'm trying to rate songs but it works only one playlist...when i choose another playlist and trying to rate songs...nothing happens. someone help me

Probably you have "library only" checked and the files in the second playlist are not in the library.

where exactly i can uncheck this "library only"?

In the preferences page.

[donnie]

Sorry if I'm being really stupid here but is it possible to transfer custom info values to a field stored in the tacks' tags using the masstagger?

[Fermion]

Sry about lack of updates, my access to internet is quite limited...

0.1 beta4
- fixed an issue where info was not correctly saved for some tracks
- fixed text file line change reading (now requires CR+LF)
- fixed file deletion within fb2k (again)
- renamed tagz functions: $ciget() -> $cinfo(), $cinum() -> $cinfo_num(), $cilist() ->$cinfo_list()
- added function $cinfo_sep(). Behaves like $meta_sep().
- fully(?) functional(?) SQLite info storage. Can also read the database created by Quicktag sql.
- whole internal acrhitecture changed. Once again, hope I didn't break anything.
- new SDK (or a "wannabe" SDK at least), completely rewritten

[Fermion]

How can we get the separate values of a multi values field as the old 'tag' (with no %%) did in albumlist or the #tag# did in PLT?

I can't figure up how to set PLT or browser panels to use the single values...


Thanks.

I must say that I'm not really familiar with almost any 0.9 components.. :/ Guess I have to do some research...

This post has been edited by Fermion: Jul 11 2006, 17:43

[BenniP]

Great plugin, thank you!

[fabiospark]

Sry about lack of updates, my access to internet is quite limited...

0.1 beta4
- fixed an issue where info was not correctly saved for some tracks
- fixed text file line change reading (now requires CR+LF)
- fixed file deletion within fb2k (again)
- renamed tagz functions: $ciget() -> $cinfo(), $cinum() -> $cinfo_num(), $cilist() ->$cinfo_list()
- added function $cinfo_sep(). Behaves like $meta_sep().
- fully(?) functional(?) SQLite info storage. Can also read the database created by Quicktag sql.
- whole internal acrhitecture changed. Once again, hope I didn't break anything.
- new SDK (or a "wannabe" SDK at least), completely rewritten

I can't see the CI commands in the context menu and I can't enable the info storing.
After I choose the storing method, if I click on "save all" or exit and then re-enter the preferences page the box is still showing "none".
Another small thing: could you make it reopen its pref page when I reopen the preferences after selecting custominfo pref page, please? Now, it always opens on the general pref page.

Thanks.

[Fermion]

I can't see the CI commands in the context menu and I can't enable the info storing.
After I choose the storing method, if I click on "save all" or exit and then re-enter the preferences page the box is still showing "none".

Did you press the "switch"-button? Did it give any warnings?

Another small thing: could you make it reopen its pref page when I reopen the preferences after selecting custominfo pref page, please? Now, it always opens on the general pref page.

Ok, I'll do that in next update.

[unabatedshagie]

I have some tags called style and featuring which I would like to copy from the files to the database, how would I go about doing this?

[fabiospark]

1) For multi values fields, in regular tagz the $meta_sep(tag,', ') gives the same output as %tag%, with custominfo fields, $cinfo_sep(tag,', ') works as it's tagz sister but
%tag% returns only the first value and not the others.
Could you do something about it?

If you can, I think we won't need the $cinfo_sep() anymore.


2) With the old QTSQL I could use the masstagger function "Format SITUATION using %__situation%" followed by "Split SITUATION field by "," separator".
With custominfo, in this way I'm getting only the first value.
If I use $cinfo_sep(__situation,', ') instead of %__situation% in the script, in columns UI I get [UNKNOWN FUNCTION] as output for %situation%.
After (if) you fix the %tag% thing, could you make everything work in masstagger (and in trackinfo too), please?

If you need some more examples let me know.


Thanks.

[Fermion]

I have some tags called style and featuring which I would like to copy from the files to the database, how would I go about doing this?

Depends on if you want to keep them in files too or not. You could create a context menu command with field name "STYLE|FEATURING" and value "%style%|%featuring%", and then appy it to the files you want. But this way you have to access them using $cinfo(style) etc., or remove style and featuring tags from files with masstagger or file properties. Or you can use different field names for custom info values ("STYLE2|FEATURING2" or whatever).

Fabio:
I certainly could make %tag% show all of the values... but that's not the issue. As you might have noticed, %tag% with custominfo fields is not recognized by masstagger either. It evaluates to "?" as if the field wouldn't exist. There is nothing I can do about it. Same thing with track info.

Also, there is no way to split/branch the entries in playlist tree or browser using %<tag>%. They access the file info structures directly and know nothing about multi-valued custom fields. In album list one could do the branching with a special hack $char(4)$cinfo_sep(tag,$char(5))$char(4), but ... I think nobody's using album list anymore... :|

Sorry about the bad news, but that's just how it is.

And this also the only (legit) way I can think of implementing these db-only tags. The tech info approach used earlier doesn't work in 0.9 anymore.

[fabiospark]

I certainly could make %tag% show all of the values... but that's not the issue. As you might have noticed, %tag% with custominfo fields is not recognized by masstagger either. It evaluates to "?" as if the field wouldn't exist. There is nothing I can do about it. Same thing with track info.

Also, there is no way to split/branch the entries in playlist tree or browser using %<tag>%. They access the file info structures directly and know nothing about multi-valued custom fields. In album list one could do the branching with a special hack $char(4)$cinfo_sep(tag,$char(5))$char(4), but ... I think nobody's using album list anymore... :|

Sorry about the bad news, but that's just how it is.

And this also the only (legit) way I can think of implementing these db-only tags. The tech info approach used earlier doesn't work in 0.9 anymore.

It's a pity.
I'm not a programmer so I beg your pardon if I'm saying something wrong:

- have you tried and asked about these preoblems in the development forum?
- have you talked to cbowron, the author of foo_browser and foo_playlist_tree?

Maybe they can give you some hints on where to go.

PS.
Is it right they don't work with foo_qiocksearch too?

Thanks.

[Fermion]

0.1.0
- some minor optimizations/fixes.
- I think it's pretty stable now, but please notify me of any bugs if you find any.
- added a command for removing dead custominfo entries (useful if files have been moved/removed outside foobar2k). It is slow, though.

- have you tried and asked about these preoblems in the development forum?
- have you talked to cbowron, the author of foo_browser and foo_playlist_tree?

Maybe they can give you some hints on where to go.

I don't think there's any need for hints, cause I already know it's a dead end.. And there's no way I'm gonna start begging other authors to change their components. I don't know how easy it would be to change the titleformatting behavior (track info, masstagger etc.) or what are the benefits of current behavior, but the branching in browser / playlist tree would propably take huge amount of extra work (and make the component slower).

Is it right they don't work with foo_qiocksearch too?

Dunno. Haven't tried.

[fabiospark]

I don't think there's any need for hints, cause I already know it's a dead end.. And there's no way I'm gonna start begging other authors to change their components. I don't know how easy it would be to change the titleformatting behavior (track info, masstagger etc.) or what are the benefits of current behavior, but the branching in browser / playlist tree would propably take huge amount of extra work (and make the component slower).

Sorry, this is the last time I bother you about it.

Read this more as a question thrown to the masstagger developer rather than at you...

I think that a good solution would be having masstagger work with custominfo fields, at least.
We could periodically transfer (copy) the custominfo fields content to regular tags.
In fact this is what I'm still doing with my FB 0.8.3: Quicktagging my files while listening to them WITHOUT DISTURBING THEM and once in a while masstagging the SQL __tags into regular tags.

If I remember well, with FB0.9 you can tag playing files but when you do it you get a gap in the playing music. Quite annoying and so unuseful. But maybe with the last new betas they have fix it...

Anyway, thanks again for your efforts.

[uberkrieg]

hello. great pluggin, thanks for releasing it.
is there a way that I can use this pluggin with the foo_playcount so it saves first_player, last_played, and play_count to the database and not to a real tag withing the file?
thanks!

[fabiospark]

hello. great pluggin, thanks for releasing it.
is there a way that I can use this pluggin with the foo_playcount so it saves first_player, last_played, and play_count to the database and not to a real tag withing the file?
thanks!

The brand new official playcount plugin already lets you do something similar.

[foosion]

foo_custominfo labelled as known potential troublemaker

foo_custominfo has been put on the list of known potential troublemakers because it wrongly assumes that metadb_display_hook methods are only called from the main thread. It thereby breaks components that run titleformatting scripts in a worker thread. Please use the "report post" feature when you announce a fixed version to notify a moderator.

[Fermion]

foo_custominfo labelled as known potential troublemaker

foo_custominfo has been put on the list of known potential troublemakers because it wrongly assumes that metadb_display_hook methods are only called from the main thread. It thereby breaks components that run titleformatting scripts in a worker thread. Please use the "report post" feature when you announce a fixed version to notify a moderator.

Is there any more detail you can give? Imho I'm doing the synchronization correctly and I'm not calling any foobar API functions inside the hooks. There were such issues in betas 2 and 3, but these should be fixed.

Thanks.

[Fermion]

Ok, now I read that topic about foosic. If you are referring to the problem causing the console error message, then it was fixed as I said above.

[foosion]

Thanks for the clarification. I missed that there is a newer version than 0.1 beta 3 when I did my tests. We will keep the entry in the list of known potential troublemakers for some weeks, though it now has information about the faulty version(s) and an update note.

[Infernus]

have some troubles with custominfo 1.0 and fb0.93b2 (I think problem was also with 0.92) and I cant really reproduce it....
Sometimes when I cange settings from plugins in the tools-selection of fb preferences and then press save all button + close: custominfo switches the storage method form "fb config file" to "none"......but not every time....???

[Fermion]

0.1.1
- bugfix: config saving caused disabling of the component (thanks, Infernus)
- bugfix: titleformatting function names were interpreted wrong in certain cases
- bugfix: weird behavior of the pref. page tab control
- date/time variables available (only!) in the context menu commands: %_system_year%, %_system_month%, %_system_day%, %_system_dayofweek%, %_system_hour%, %_system_minute%, %_system_second%, %_system_millisecond%
- some internal improvements

[unabatedshagie]

A couple of questions:

1. Is there no way of editing the current information for the tracks other than completely overwriting it?

2. How do you remove stored information from a track?

And now a bug (of sorts):

1. The date/time variable fields are not padded with leading zero's

Finally a feature request:

1. Have an option to create a backup of the database incase of corruption, accidential deletion etc?

This post has been edited by unabatedshagie: Jul 24 2006, 05:09

[Fermion]

1. Is there no way of editing the current information for the tracks other than completely overwriting it?

Not atm. Maybe I'll add such a feature, maybe not.

2. How do you remove stored information from a track?

Right now it's possible only to remove single fields by setting an empty value to it and having the removal of empty fields turned on in the preferences. Or remove multiple fields with the FIELD1|FIELD2|FIELD3 syntax and leaving the value string empty. But I could work out something more practical...

1. The date/time variable fields are not padded with leading zero's

That's the way it was meant to be.

1. Have an option to create a backup of the database incase of corruption, accidential deletion etc?

I don't know if that's really necessary. I mean you can manually copy the database file / fb2k config file, or create some script or batch file to do it automatically.

[Der_Iltis]

Does this plugin work with the freedb tagger so that I can add freedb data to database only?