You are here: Home » Topic » SQLite Prob on NSLU2

SQLite Prob on NSLU2

This topic contains 21 replies, has 3 voices, and was last updated by  rpedde 13 years, 10 months ago.

Viewing 15 posts - 1 through 15 (of 22 total)
  • Author
  • #53


    Hello, maybe somebody can help me with this, it’s driving me nuts. I can’t get the daemon to start at all and I’ve never dealt with SQLite. Below is a sample log with the problem in bold. About all I’ve tried is to get rid of the songs.db file and restart but it doesn’t help.

    2005-05-09 08:09:16: Starting rendezvous daemon
    2005-05-09 08:09:16: Starting signal handler
    2005-05-09 08:09:16: db_sqlite_open: malformed database schema – unable to open a temporary database file for storing temporary tables /opt/var/mt-daapd/songs.db)
    2005-05-09 08:09:16: Aborting
    2005-05-09 08:09:16: Rendezvous socket closed (daap server crashed?) Aborting.
    2005-05-09 08:09:16: Aborting

    Any takers? I would really appreciate it!




    I think that means that the “runas” user doesn’t have write permission to /opt/var/mt-daapd.

    Double-check your permissions — try “chown user /opt/var/mt-daapd” where user is the user specified in your “runas”.



    Ok, I tried that with a user of ‘guest’ and of ‘nobody’ and still get the same error. Also, after I changed the owner, I deleted the db file before trying to start up. I’m really lost here. The perms look right to me.

    # ls -l
    -rw-r–r– 1 nobody nobody 0 May 9 09:04 songs.db



    Not the .db file, but the directory it’s sitting in (/opt/var/mt-daapd).

    If the “runas” user can’t create files in /opt/var/mt-daapd, that’s when you get the error described.

    So check to see that /opt/var/mt-daapd is owned by the user that is the “runas”, and delete the songs.db file. Then start it and see where you get.

    — Ron

    p.s. you can check this interactively by doing “su guest”, then changing to /opt/var/mt-daapd and see if you can create a file.

    slug:/# su guest
    slug:/$ cd /opt/var/mt-daapd
    slug:/opt/var/mt-daapd$ touch test.fil

    if that won’t work, then mt-daapd won’t work either.

    — Ron



    Ok, I verified all that and can create a file in that dir no problem. This is a strange one.



    what about /tmp? That should be world writable.



    Yay! /tmp was it, the write bits were missing for group and user. Now the server starts up ok and I can navigate the admin pages. It’s not registering the songs in the directory yet for some reason but I’ll poke around a bit and see what might be causing that. But just getting it started and having iTunes see it is fun enough for tonight.

    Thanks for your help.



    Again, that’s very likely permissions. Check that your permissions on the mp3 files are readable by the runas user.

    I think it’s probably got correct permissions if it’s running as guest.



    I’m a little new to Linux perms and I’m still having probs with startup. It says that it “scanned 0 songs in 3 seconds”.

    Do these perms look ok to you? Seems like they might even be too loose but I wanted to eliminate any problems.

    drwxrwxrwx 2 guest everyone 4096 May 11 22:18 music



    Those permissions are as liberal as they can get — though a little overkill. IME, 755 is sufficient for use with mt-daapd.

    That said, if you are seeing “scanned 0 songs in 3 seconds” you may want to ensure that the library path (“mp3_dir”) in the configuration file is accurate. On a slug it should be something like /share/hdd/data/…/.




    I’m still having no luck after quite a bit of troublehooting. Still get the ‘scanned 0 songs in 3 seconds’ on startup of the daemon. Would perms on the files themselves be a problem? I am unable to change settings for the actual mp3s for some reason.

    The perms for the files are:

    -rwxrw—- 1 guest everyone 51240 Apr 2 13:13 01 Stupid Daniel.m4a



    It probably is permissions on the songs.

    Try turning on logging on mt-daapd. Add a log file in your config file. I usually use “/share/hdd/public/mt-daapd.log”, because that sits right in the DISK 1 share, and it’s easy to get to from a client.

    Then change /opt/etc/S60mt-daapd and add “-d5”, so it looks like:

    /opt/sbin/mt-daapd -d9 -c /opt/etc/mt-daapd/mt-daapd.conf

    then run mt-daapd and look at your logfile. It should tell you why it’s not finding anything.



    This is weird, the log shows very little…

    2005-05-18 18:28:10: Starting rendezvous daemon
    2005-05-18 18:28:10: Starting signal handler
    2005-05-18 18:28:12: Initializing database
    2005-05-18 18:28:12: Full reload…
    2005-05-18 18:28:12: Starting mp3 scan
    2005-05-18 18:28:12: Starting web server from /share/hdd/data/public/conf/opt/share/mt-daapd/admin-root on port 3689
    2005-05-18 18:28:12: Registering rendezvous names
    2005-05-18 18:28:12: Scanned 0 songs in 2 seconds



    Assuming that’s really at debug level 5 (guess I should print the debuglevel at startup, huh?) then the only problem can be that there aren’t any files in the mp3_dir.

    Otherwise it should be printing errors about why it couldn’t scan them.

    Are you sure that your mp3_dir is pointing to where your mp3 files are?



    Yup, I’ve checked and double-checked the settings for the music folder (along with everything else) I’m really at a loss. It’s interesting that even when I specify level 5 debug, there’s no difference in the output! Makes me wonder if it’s even taking that parameter.

    It doesn’t help that I’m fairly new to Linux but I get the idea of it. I’ve been administering apps on Slackware for quite some time. Figured if I could handle that distro, I could handle anything. Guess not…

Viewing 15 posts - 1 through 15 (of 22 total)

The forum ‘Setup Issues’ is closed to new topics and replies.