Nightly build for NSLU2

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #161
    swarner
    Guest

    Hi Ron,

    I’m not a unix or programming techie, so is it possible to post the compiled version of the nightlies for the slug?

    You used to do this, so I guess you just haven’t had the time to continue it? But I’d like to be able to install the latest version.

    Cheers,

    Steve

    #3914
    rpedde
    Participant

    Yup, I will. My x86 machine is gone, and I’m now trying to build slug packges on a slug running debonaras. But I was having problem getting the build environment running.

    I think it’s working now, though, so I’ll start building slug packages again with the next nightly.

    — Ron

    #3915
    UncleOp22
    Participant

    rpedde wrote:

    :

    I think it’s working now, though, so I’ll start building slug packages again with the next nightly.

    I see the new ipkg there. So – do I have to manually install sqlite3, or will my current sqlite2 install work OK? And you say on the nightlies page:

    759.7 Kb (3 d/l)
    mt-daapd_cvs-20060116-1_armeb.ipk 508.2 Kb (0 d/l)

    Fixes for the “can’t start enum” problems people have reported, as well as the problems with filenames with a % in their name.

    some configure changes… watch for anything strange there. You will now have to specify either (or both) –enable-sqlite or –enable-sqlite3 now. You will get an error if you forget to specify one.

    Errors should now display on the web interface when you try to add a playlist but it doesn’t parse. I’ll work on making those errors more descriptive — I just wanted to be able to push errors from the parser back up to the web interface.

    No really big changes, then, just a bunch of fixes.

    Soooo: do I need to specify “–enable-sqlite” or “–enable-sqlite3” if I’m using sqlite2? (sorry to be dense; dependencies are always a bit mind-boggling…)

    -Del

    #3916
    rpedde
    Participant

    If you install the .ipk, it should notice that you don’t have sqlite 3.x and install it automagically.

    that’s the theory, anyway. If it fails, I’d like to hear about it. If it does, you can try manually installing the sqlite3 libs (ipkg install sqlite).

    — Ron

    #3917
    UncleOp22
    Participant

    rpedde wrote:

    If you install the .ipk, it should notice that you don’t have sqlite 3.x and install it automagically.

    that’s the theory, anyway. If it fails, I’d like to hear about it. If it does, you can try manually installing the sqlite3 libs (ipkg install sqlite).

    The install went OK, once I did a “ipkg update”.

    Got yer run-time errors right here:

    2006-01-16 21:14:58: Starting rendezvous daemon
    2006-01-16 21:14:58: Starting signal handler
    2006-01-16 21:14:59: Can't get db version. New database?
    2006-01-16 21:14:59: Initializing database
    2006-01-16 21:14:59: Full reload...
    2006-01-16 21:14:59: Starting mp3 scan of /share/hdd/data/nathan/nathan/music/ogg
    2006-01-16 21:14:59: Query: pragma synchronous = off
    2006-01-16 21:14:59: Error: file is encrypted or is not a database
    2006-01-16 21:14:59: Aborting
    2006-01-16 21:14:59: Rendezvous socket closed (daap server crashed?) Aborting.
    2006-01-16 21:14:59: Aborting

    That’s all that’s in the log file with the default logging level.

    My install went like this:

    # ipkg install mt-daapd_cvs-20060116-1_armeb.ipk
    Upgrading mt-daapd on root from cvs-20051122-1 to cvs-20060116-1...
    Installing sqlite (3.2.8-1) to root...
    Downloading http://ipkg.nslu2-linux.org/feeds/unslung/cross/sqlite_3.2.8-1_armeb.ipk
    Configuration file '/opt/etc/mt-daapd/mt-daapd.conf'
    ==> File on system created by you or by a script.
    ==> File also in package provided by package maintainer.
    What would you like to do about it ? Your options are:
    Y or I : install the package maintainer's version
    N or O : keep your currently-installed version
    D : show the differences between the versions (if diff is installed)
    The default action is to keep your current version.
    *** mt-daapd.conf (Y/I/N/O/D) [default=N] ?Y

    And then I hand-edited the mt-daapd.conf file to include my changes (new admin pw, log file on, 3600 second refresh).

    I’ll dig around more. Happy for hints if you think of them first.

    #3918
    rpedde
    Participant

    That comes from one of two things:

    1. Either there is a songs.db-journal sitting in your db_dir
    or
    2. The database is the wrong type — a sqlite2 database, and you told it to use sqlite3, or vice-versa.

    whack whatever is in your db_dir and try again.

    — Ron

    #3919
    UncleOp22
    Participant

    So I did “ipkg remove” for both mt-daapd and sqlite and sqlite3. Then I reinstalled, based on the nightly ipkg:

    # ipkg install mt-daapd_cvs-20060116-1_armeb.ipk
    Installing mt-daapd (cvs-20060116-1) to root...
    Installing sqlite2 (2.8.16-1) to root...
    Downloading http://ipkg.nslu2-linux.org/feeds/unslung/cross/sqlite2_2.8.16-1_armeb.ipk
    Configuring mt-daapd



    To complete this installation, make any necessary changes
    to the config file in /opt/etc/mt-daapd/mt-daapd.conf, and
    start the daemon by running /opt/etc/init.d/S60mt-daapd

    Configuring sqlite2

    # sqlite -version
    2.8.16

    I then goofed and forgot to enable the logfile before starting, but the slug is definitely busy. So it looks like for slugs the nightlies prefer sqlite 2, but I saw fer shur that my prior attempt put up version 3.2.8-1. I’m a little confused, but things seem to be up for now.

    So, are there any pitfalls I should be aware of based on the sql version differences? (Or should I just go read the diffs in CVS?)

    Oh, and joy! It seems that my old smart playlists, from before the “ipkg remove” steps above, are still there, so I guess my old DB didn’t get completely nuked. Another intentional artifact?

    #3920
    rpedde
    Participant

    ipkg remove just gets rid of the binaries, not the config files or the data files.

    The default config file does prefer sqlite2, yes, although the package on the nightlies page has support for either sqlite2 or sqlite3.

    If you choose one or the other, you need to get rid of your existing database: /opt/var/mt-daapd/songs.db. sqlite2 can’t open a sqlite3 database, and vice-versa. So if you switch types (sqlite2/3), you need to nuke your songs.db. That means your smart playlists are gone, though.

    A workaround might be to convert the sqlite2 to sqlite3. You can do something like this:


    slug$ sqlite /opt/var/mt-daapd/songs.db .dump | sqlite3 /opt/var/mt-daapd/songs3.db
    slug$ mv /opt/var/mt-daapd/songs.db /opt/var/mt-daapd/songs2.db
    slub$ mv /opt/var/mt-daapd/songs3.db /opt/var/mt-daapd/songs.db

    And the oppose for sqlite3 to sqlite2.

    — Ron

Viewing 8 posts - 1 through 8 (of 8 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.