Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: [Request]Foo_quicktag + sqlite.dll (Read 39985 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[Request]Foo_quicktag + sqlite.dll

Reply #25 –
Quote
Quote
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.

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?
[a href="index.php?act=findpost&pid=282475"][{POST_SNAPBACK}][/a]

foo_pod will set the metadata directly - the only thing you have to handle is the on_info_edited(), which should be fired as soon as foo_pod modifies the metadata.

[Request]Foo_quicktag + sqlite.dll

Reply #26 –
Quote
Quote
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.
[a href="index.php?act=findpost&pid=281350"][{POST_SNAPBACK}][/a]

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
[a href="index.php?act=findpost&pid=281823"][{POST_SNAPBACK}][/a]

Maybe this is because it would require changes to the core - which means it would require a new fb2k version. Combine this with the fact that peter is keeping a low profile when it comes to what will be in the next version, and there you have the reason why you rarely read about implementation on these forums.

The fact that there is no talk about implementation of this feature is no indication of the propability of implementation. Having DB-only tags and DB-autoupdate is among the most wanted features for the core, so you can bet that peter is aware of it - if he will implement it of course is a different question.

- Lyx
I am arrogant and I can afford it because I deliver.

[Request]Foo_quicktag + sqlite.dll

Reply #27 –
Quote
Maybe this is because it would require changes to the core - which means it would require a new fb2k version.[a href="index.php?act=findpost&pid=282778"][{POST_SNAPBACK}][/a]
Not only that, such a change would also permeate all metadata related parts of the API. This is nothing one would do with a little hand-waving.

[Request]Foo_quicktag + sqlite.dll

Reply #28 –
Wouldnt it be possible to just have a list of tags which shouldnt be updated to the file? Or better, a list of tags that should be updated to the file? (I personnally would have an empty list) This could be done with just a small configuration change to the database component AFAIK. Though admittedly Id like to see a nicer solution, which would indeed permeate the metadata related parts of the API.

Id really like to see this done. For me, that, and no media library which suits my needs, are the main reasons for not using or developing for foobar2000, though Id really like to. Id even write a media library myself, though the current database/tag implementation in fb2k would need to be altered before Id consider starting.

This SQL stuff seems closer to what Id like to see, though itd be good to see it implemented natively and supported by the database. Having two lots of database code seems like a waste. And Im not sure how heavyweight the sqllite stuff is compared to the native database. Admittedly I havent experimented much with it, so it could be better than I think.

[Request]Foo_quicktag + sqlite.dll

Reply #29 –
Does Quicktag+sqllite support multiple values in a field (or multiple fields with the same name)?

[Request]Foo_quicktag + sqlite.dll

Reply #30 –
Quote
Does Quicktag+sqllite support multiple values in a field (or multiple fields with the same name)?
[a href="index.php?act=findpost&pid=283074"][{POST_SNAPBACK}][/a]

I don't think so. i.e. rate a song, and rate it again with another value and it'll have the first rate replaced by the last one.

[Request]Foo_quicktag + sqlite.dll

Reply #31 –
Quote
Quote
Does Quicktag+sqllite support multiple values in a field (or multiple fields with the same name)?
[a href="index.php?act=findpost&pid=283074"][{POST_SNAPBACK}][/a]

I don't think so. i.e. rate a song, and rate it again with another value and it'll have the first rate replaced by the last one.
[a href="index.php?act=findpost&pid=283087"][{POST_SNAPBACK}][/a]


I agree about rating but I was thinking that it could have been a clever way to get round that WMA problem with multiple values fields (it seems you can't have them).

If only we could choose if a field must be unique or not....

[Request]Foo_quicktag + sqlite.dll

Reply #32 –
Quote
This SQL stuff seems closer to what Id like to see, though itd be good to see it implemented natively and supported by the database. Having two lots of database code seems like a waste. And Im not sure how heavyweight the sqllite stuff is compared to the native database. Admittedly I havent experimented much with it, so it could be better than I think.[a href="index.php?act=findpost&pid=282847"][{POST_SNAPBACK}][/a]
I implemented a simple component to export the contents of the foobar2000 database to a SQLite 3 database. The SQLite database uses the following schema:
Code: [Select]
CREATE TABLE tracks (url TEXT, subsong INTEGER, PRIMARY KEY (url, subsong));
CREATE TABLE meta (trackid INTEGER, name TEXT, value TEXT);
CREATE TABLE info (trackid INTEGER, name TEXT, value TEXT);

The trackid column in the meta and info tables holds the rowid of the associated track. While this is certainly not the nicest database schema, it is capable of storing arbitrary field names and multiple values in one field*. Needless to say, queries can get quite ugly with this, for example to get the locations of all songs by Queen you would have to use something like
Code: [Select]
SELECT * FROM tracks WHERE rowid IN (SELECT trackid FROM meta WHERE name LIKE 'artist' AND value LIKE 'queen');

I don't know how fast SQL queries on this database are compared to queries on the native foobar2000 database (using playlist generator style filters or another method). I have however measured the time to create and populate the SQL database (done in a single transaction of course); it is more than ten times slower than writing an FPL playlist containing the same information.

*: Exactly what makes the database schema so cumbersome, but also key features of foobar2000.

[Request]Foo_quicktag + sqlite.dll

Reply #33 –
As you say, that schema is pretty inefficient, and is the biggest contributor to the performance difference. I think a better schema could give you similar if not better performance. Perhaps it would be possible to have something like (not a db wiz here):

TABLE url, trackid, extraid (primary key trackid)
TABLE trackid, title, artist, album, year, genre, rating, playcount
TABLE extraid, metaname, metavalue

ie, all the most common stuff could be stored directly in the main table or reference table, and use a separate table for any extra uncommon tags. Its expected that populating is going to be a fair bit slower, as it needs to do all the key cross referencing and hashing etc, esp if you are using the url as a primary key. But the slowness in populating can also aid in the retrieval, as it builds indexes etc for faster lookups (AFAIK). Also remember to do an 'unsynched' insertions, as otherwise the file is flushed everytime. Though with a single transaction I would assume this doesnt matter.

Retrievals and edits could possibly be much faster, afterall, that is pretty much the primary goal of sqllite. If it can't do that faster than a flatfile, you gotta wonder why you would use it. Populating a very basic db that isnt much more than a flatfile is pretty much a given that its going to be fast, but it will have drawbacks doing anything else.


Besides all this, is it possible to build a foo_database component that completely replaces the database? Id certainly like to see a better database that doesnt automatically assume you want everything synched to the file, and other nitpicks.

But I guess we should wait and see what fb2k 0.9 brings.

[Request]Foo_quicktag + sqlite.dll

Reply #34 –
v.1.1 available, with database synchronization, setting multiple fields at a time, and lowercase tech info support.

[Request]Foo_quicktag + sqlite.dll

Reply #35 –
Quote
Besides all this, is it possible to build a foo_database component that completely replaces the database? Id certainly like to see a better database that doesnt automatically assume you want everything synched to the file, and other nitpicks.[a href="index.php?act=findpost&pid=283287"][{POST_SNAPBACK}][/a]
The metadb service is implemented in the core (read: foobar2000.exe). It cannot be replaced by a separate component.

To prevent misconceptions about the database/metadb, let me recap what it is designed to do: First and foremost, it caches metadata about the currently used tracks in memory, so that this data can be accessed efficiently when needed. The primary place where tracks are used are the open playlists.
The second aspect of the  metadb is that of a library; it basically manages a set of tracks that are known to the system, even if they are currently not on a playlist. This part is optional an can be enabled on the "Database" page in preferences.

Back on the topic of a completely SQL based database: I know comparing the time needed to populate an SQL database with the time needed to write an FPL file is not very meaningful; it is however currently the best thing (for me) to get a feeling for the performance of SQLite. I initially planned to do some more performance tests (like searching tracks based on metadata or retrieving metadata for given tracks), but after experimenting a bit with the exported database using the command line version of SQLite3, I realized how cumbersome this sort of task would be and gave up on the whole idea.

Lastly, I'm not in the position to decide that the implementation of the metadb should be changed, but I would currently advise against using a solution based on relational databases due to the following points: Using a relational database would mean reducing the functionality (restricting the kind and number of supported tags) or reducing the performance (full metadata support like in my experiment). Hybrid schemes are possible, but only offer a trade-off between reduced functionality and reduced performance while adding complexity.
Regarding better support for searching offered by relational databases: This is only a benefit in the reduced-functionality setting. With support for arbitrary tags and duplicate tags, writing anything but very simple queries is a real chore, and the resulting queries are not very efficient (nested SELECT statements or similar constructs).
The current implementation on the other hand offers very fast access to the metadata of a given track (unless the data is not up-to-date and has to be retrieved from the actual file, which can also occur with the SQL approach). The time needed to access a particular field on a track only depends on the number of fields stored for that track, not on the total number of tracks or fields known to the system. Based on this, a search operation can be implemented as a linear sweep over the tracks in the "database" (or any other list of tracks). By using library functions (for example, the filter code used by the playlist generator will be available in the helper library in the 0.9 SDK), filtering a list of tracks and sorting the results can be implemented in a few lines of code.

[Request]Foo_quicktag + sqlite.dll

Reply #36 –
I wanted to let the author know that there is a problem updating tags in flac files with embedded cuesheets. It is making foobar2000 v0.8.3 crash, by hanging after clicking the "Update" button. Actually, it was a "Not Responding". It is also happening with kode's "foo_playcount", as well. Could the sqlite.dll be causing a conflict? Also, I tried running each separately, but still the same problem. Removing them both cleared the problem right up.
Surf's Up!
"Columnated Ruins Domino"

[Request]Foo_quicktag + sqlite.dll

Reply #37 –
@Fermion,

Is there any chances to know if there's any news in the implemention of this:

Quote
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.
[a href="index.php?act=findpost&pid=282642"][{POST_SNAPBACK}][/a]


...I can't wait to transfer my%added% tag to %_added% tag

I've also the feeling that foo_playcount_mod and your foo_quicktag_sql belong somehow together as both stores info on an external sql database, and the only difference between them is:

- foo_playcount can sotre systemdate values.
- foo_playcount update the meta-data info in the db everytime a track is played.

Implementing these two features (store systemdate values + an option to update a value everytime is played) will be great and will only make use of 1 external db file.
 

[Request]Foo_quicktag + sqlite.dll

Reply #38 –
Working perfectly for me.

Speaking of saving to db though.

Is there a way to save replay gain info to database?

Because atm every time I redo my mp3s it looses the replay gain info. Since I am now using this verison of quicktag and sqlite plus the new playtime one that uses sqlite I dont loose that info anymore like I use to but I still loose replay gain.

Thanks,
  Will
God Bless U.S.A

[Request]Foo_quicktag + sqlite.dll

Reply #39 –
Hi,

Sorry to bump this thread (I hope I'm not bothering you Fermion) but is there any chances that this could be implemented? 

[Request]Foo_quicktag + sqlite.dll

Reply #40 –
foo_quicktag_sql v.1.2

Quote
I wanted to let the author know that there is a problem updating tags in flac files with embedded cuesheets. It is making foobar2000 v0.8.3 crash, by hanging after clicking the "Update" button. Actually, it was a "Not Responding". It is also happening with kode's "foo_playcount", as well. Could the sqlite.dll be causing a conflict? Also, I tried running each separately, but still the same problem. Removing them both cleared the problem right up.
[a href="index.php?act=findpost&pid=286147"][{POST_SNAPBACK}][/a]

Thanks. I believe i fixed it now. Updating cuesheets caused the metadata to reload while the metadb handle was still in use, resulting in a deadlock with another critical section. There's still the same bug in playcount plugin, so perhaps i should fix that too...

Quote
Is there a way to save replay gain info to database?
[a href="index.php?act=findpost&pid=289235"][{POST_SNAPBACK}][/a]

Propably not the best solution, but it could be done by using replaygain to scan the values when "block tag update operations" is enabled, and then force quicktag to update the values to the external database with the following syntax:
field name
REPLAYGAIN_TRACK_GAIN|REPLAYGAIN_TRACK_PEAK|REPLAYGAIN_ALBUM_GAIN|REPLAYGAIN_ALBUM_PEAK
value
%__REPLAYGAIN_TRACK_GAIN%|%__REPLAYGAIN_TRACK_PEAK%|%__REPLAYGAIN_ALBUM_GAIN%|%__REPLAYGAIN_ALBUM_PEAK%

[Request]Foo_quicktag + sqlite.dll

Reply #41 –
Hi Fermion,

The FLAC tags updating is indeed fixed. It is working as expected. Thank you for fixing the plugin! Also, it would be very nice of you to fix the foo_playcount SQL Version. It would be most appreciated. Thanks again.
Surf's Up!
"Columnated Ruins Domino"

[Request]Foo_quicktag + sqlite.dll

Reply #42 –
@Fermion

Thank you very much. The system dates are working perfectly.

[Request]Foo_quicktag + sqlite.dll

Reply #44 –
Why 1.2 asks for MSVCRTD?

It's only me?

Till 1.1 no problems.

--------------------------

Is there a way to build a quick tag that asks me for a value (or part of it)?
Something like: value $user_input()
I'm thinking to use it as a bookmarker so one could add whatever he likes without having to thinking in advance.
E.g: I'm listening to those files I tagged as "Sunny" (in bulk) and I come across a not too sunny track so I just need to bookmark it with something as "Remove from Sunny" where "Remove from" is the written value of a BOOKMARK 1 field and Sunny" is the text I add when I trigger the tagging.

Thanks.

[Request]Foo_quicktag + sqlite.dll

Reply #45 –
Quote
Why 1.2 asks for MSVCRTD?
[{POST_SNAPBACK}][/a]


I had the same problem. Download it from [a href="http://www.dll-files.com/dllindex/dll-files.shtml?msvcrtd]here[/url] and put it in your foobar root dir.

[Request]Foo_quicktag + sqlite.dll

Reply #46 –
v.1.3
Please test it well, I had to change some things quite a lot to make the user input work..

fabiospark:
does it work now the way you wanted?

[Request]Foo_quicktag + sqlite.dll

Reply #47 –
Question to anybody. I use the original foo_quicktag. For visual indication, I add via context menu and with help of foo_quicktag,

Description: flag track, FLAG=1
and
Description: unflag track, FLAG=[EMPTY] (which deletes FLAG)

I'd like, for some visual reasons, to also remove another tag. Is there any way?

I mean, on: "unflag track" I'd like to have TRACKNUMBER and FLAG removed. 2 Actions. Possible?

[Request]Foo_quicktag + sqlite.dll

Reply #48 –
Quote
fabiospark:
does it work now the way you wanted?
[a href="index.php?act=findpost&pid=295022"][{POST_SNAPBACK}][/a]


Yes, it does.

In Italy we say: "l'appetito vien mangiando" (eating, one gets hungrier) - so, let me go further with some feature requests:

1)  It would be nice having more than one field editable in the same dialog window(and then you can think of removing "Quick" from the plugin name and call it just tagger)

2)  If you do that, you should also think to modify the normal (not MySql) QuickTag so to be able to work the same way but into files directly (the properties window way of tagging it's really cumbersome)

3  If you do that, you should also think to enable multiple values fields (a key feature of FB).
This point 3, would be very useful even with Mod QuickTag.

It comes to me right now:  why don't mix the sql and the not one in just one plugin and add a checkmark to each quicktag string so to let the user decide if it has to be in or out the audio files?

Thanks.

[Request]Foo_quicktag + sqlite.dll

Reply #49 –
Quote
It comes to me right now:  why don't mix the sql and the not one in just one plugin and add a checkmark to each quicktag string so to let the user decide if it has to be in or out the audio files?
[a href="index.php?act=findpost&pid=295273"][{POST_SNAPBACK}][/a]

That will be really nice.