This topic contains 5 replies, has 1 voice, and was last updated by Marco 12 years, 4 months ago.
4th November 2005 at 3:04 pm #118
I’m trying to get mt-daapd-cvs-20051101.tar.gz to work on my system but it just doesn’t want to start.
./configure –disable-sqlite (*)
(*) I have to disable sqlite since CentOS4 uses sqlite3 and there are no sqlite2 rpms available for me.
cp contrib/mt-daapd.conf /etc (and edit)
cp contrib/mt-daapd.playlist /etc
The runas user is nobody and I’ve made sure this user can write to /var/cache/mt-daapd. I’ve even changed the runas to root and the same error keeps coming back.
This does not happen with the latest stable build, 0.2.3
#mt-daapd -d 9 -m -f
Read web_root: /usr/local/share/mt-daapd/admin-root
Read port: 3689
Read admin_pw: mt-daapd
Read db_dir: /var/cache/mt-daapd
Read mp3_dir: /data/2/Music
Read servername: Cobus
Read runas: root
Read playlist: /etc/mt-daapd.playlist
Read extensions: .mp3,.m4a,.m4p
Read logfile: /var/log/mt-daapd.log
Read scan_type: 0
Read compress: 1
Checking existence of /data/2/Music
Checking existence of /var/cache/mt-daapd
Starting with debuglevel 9
Starting signal handler
Strace is attached
Post edited by: Marco, at: 2005/11/04 07:04
Post edited by: Marco, at: 2005/11/04 07:054th November 2005 at 3:06 pm #3768
Strace can be found here [file name=stracemarco.txt size=13197]http://www.mt-daapd.org/components/com_simpleboard/uploaded/files/stracemarco.txt[/file]4th November 2005 at 10:07 pm #3769
This topic is covered quite well in previous posts and in the FAQ.
Your problem is the use of the disable switch for SQLite during configuration. Development versions of mt-daapd in the nightlies after 11 March require SQLite. The disable switch was only applicable during the transitional period of the nightly builds, which could go both ways with respect to database engine; that being the version released on 05 March.
The daemon is incompatible, at present, with SQLite 3.x. Therefore, if you want to use the nightlies you must install SQLite version 2.x…period. The lack of an .rpm simply means you will need to compile from source — assuming this is possible; I am not familiar with CentOS.
Stable release 0.2.3 works, because it is based upon the old database engine, gdbm. Therefore, it has nothing to do with the presence or absence of SQLite.
–Herman5th November 2005 at 1:00 am #3770
My appologies for not having read the faq, I normally always do this so I feel quite stupid for not having read it…
Unfortunately I am unable to just use sqlite2 since it will most certainly break my system, CentOS x is a rebuild of the source RPMS of RedHat Enterprise x. I’ve tried to rebuild the sqlite2 srpms from Fedora Core 4 but sofar I’ve been unable to rebuild them succesfully.So it seems I’ll have to stick with the latest stable build for now, which is unfortunate since I was looking forward to using a database for my songs instead of the current flat file.5th November 2005 at 2:14 am #3771
Forgive my ignorance if I am misunderstanding your plight and, again, I have zero familiarity with CentOS, but I was able to find an RPM for SQLite-2 on CentOS 4. The page title identifies it to be a “CentOS 4 FExtras SRPMS”. According to the description, it “contains static library and header files for developing applications using sqlite”, which is what is needed to get the mt-daapd nightlies to compile.
Your recent reply leaves me wondering if you do not understand that it is possible to have both SQLite-2 and SQLite-3 installed on the same machine, simultaneously, with no ill effect. The library and header files have different names.
–Herman5th November 2005 at 2:34 am #3772
I do understand that it is possible to use both sqlite2 and sqlite3 on the same system, but I’ve been trying to get sqlite2 to work next to sqlite3 on CentOS but I only got dependancy errors in return. Thanks for finding this RPM for me, I’ll give it a try right away 🙂
You must be logged in to reply to this topic.