revision-number not incrimented when songs removed?

[leedo]

Hi there,

I originally posted this in the “nightly feedback” forum, but it looks like this forum is where most bug reports are going.

I am running the latest nightly on Debian unstable (2.6.23 kernel) and everything is working great. I have been playing around with adding automatic DAAP refreshing to Rhythmbox, but from the debug output it seems that mt-daapd is not reporting a new revision-number when songs are removed from the database. Is this intentional? If so how can a client find out when songs have been removed?

Thanks for any clarification or help with this issue 🙂

[rpedde]

@leedo wrote:

Hi there,

I originally posted this in the “nightly feedback” forum, but it looks like this forum is where most bug reports are going.

I am running the latest nightly on Debian unstable (2.6.23 kernel) and everything is working great. I have been playing around with adding automatic DAAP refreshing to Rhythmbox, but from the debug output it seems that mt-daapd is not reporting a new revision-number when songs are removed from the database. Is this intentional? If so how can a client find out when songs have been removed?

Thanks for any clarification or help with this issue 🙂

I had started to work toward incremental updates, but at that point I really didn’t have enough information in the sessions to do so. So I stopped worrying about it and stopped advertising dmap.supportsupdate.

I guess I can bump the db number on a delete, but I still don’t really support the update protocol properly.

[leedo]

@rpedde wrote:

@leedo wrote:

Hi there,

I originally posted this in the “nightly feedback” forum, but it looks like this forum is where most bug reports are going.

I am running the latest nightly on Debian unstable (2.6.23 kernel) and everything is working great. I have been playing around with adding automatic DAAP refreshing to Rhythmbox, but from the debug output it seems that mt-daapd is not reporting a new revision-number when songs are removed from the database. Is this intentional? If so how can a client find out when songs have been removed?

Thanks for any clarification or help with this issue 🙂

I had started to work toward incremental updates, but at that point I really didn’t have enough information in the sessions to do so. So I stopped worrying about it and stopped advertising dmap.supportsupdate.

I guess I can bump the db number on a delete, but I still don’t really support the update protocol properly.

I don’t think the lack of incremental updates is a big deal, but increasing the db number on a delete would be awesome. I took a look at the source but did not see where to add this. Any hints?

Thanks for your continued work, it is very impressive.

[rpedde]

@leedo wrote:

@rpedde wrote:

@leedo wrote:

Hi there,

I originally posted this in the “nightly feedback” forum, but it looks like this forum is where most bug reports are going.

I am running the latest nightly on Debian unstable (2.6.23 kernel) and everything is working great. I have been playing around with adding automatic DAAP refreshing to Rhythmbox, but from the debug output it seems that mt-daapd is not reporting a new revision-number when songs are removed from the database. Is this intentional? If so how can a client find out when songs have been removed?

Thanks for any clarification or help with this issue 🙂

I had started to work toward incremental updates, but at that point I really didn’t have enough information in the sessions to do so. So I stopped worrying about it and stopped advertising dmap.supportsupdate.

I guess I can bump the db number on a delete, but I still don’t really support the update protocol properly.

I don’t think the lack of incremental updates is a big deal, but increasing the db number on a delete would be awesome. I took a look at the source but did not see where to add this. Any hints?

Thanks for your continued work, it is very impressive.

Not very trivially done, as the db stuff is pretty hackish (part of the reason for the db re-write), but…

you can change db-generic.c from:

static int db_revision_no=2;                          /**< current revision of 

the db */

to

int db_revision_no=2;                          /**< current revision of 

the db */

add:

extern int db_revision_no

to db-generic.h, and doctor up db-sql-sqlite2.c (or db-sql-sqlite3.c) from this:

} else {

db_sqlite2_exec(NULL,E_FATAL,"delete from songs where id not in (select id from updated)");

to

} else {

db_sqlite2_exec(NULL,E_FATAL,"delete from songs where id not in (select id from updated)");

if(sqlite_changes(db_sqlite_handle()) db_revision_no++;

(or if(sqlite3_changes(db_sqlite3_handle()) db_revision_no++; for sqlite3).

Ugly and hackish, but there you go.

— Ron

[leedo]

Awesome. I was close, but didn’t know about the sqlite_changes function. Thanks for the help. 🙂

[rpedde]

@leedo wrote:

Awesome. I was close, but didn’t know about the sqlite_changes function. Thanks for the help. 🙂

np. I’ll roll something like this into upcoming nightlies.

— Ron

[Author]

Posts