You are here: Home » Topic » revision-number not incrimented when songs removed?

revision-number not incrimented when songs removed?

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues revision-number not incrimented when songs removed?

This topic contains 5 replies, has 2 voices, and was last updated by  rpedde 9 years, 10 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #2169

    leedo
    Participant

    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 🙂

    #16063

    rpedde
    Participant

    @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.

    #16064

    leedo
    Participant

    @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.

    #16065

    rpedde
    Participant

    @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

    #16066

    leedo
    Participant

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

    #16067

    rpedde
    Participant

    @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

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.