I've built a cgi collection browser using the collection.db and Amarok's album art directories to make a site to display my CD collection, it worked great as long as I used collection.db's from Linux machines.  I just tried using a collection.db from a Mac, and it breaks.

Using sqlite3 from the command line, I get an "unsupported file format" error trying to init the file.  Amarok still reads the file just fine, but I tried deleting the collection and rescanning with the same results.  If I bring down a collection.db from my Linux PC to the Mac, sqlite3 will handle it fine.  I haven't checked to see if I can make Amarok corrupt the file by using it on a Mac.

Both machines are running Amarok 1.4.4, KDE 3.5.5 and Qt 3.3.7.  One of the Macs involved has two versions of Sqlite, but both have the same "unsupported file format" issue when reading the file, and it happens on all the Macs I've tried (all two of 'em).

I'm sort of stumped.  It kind of looks like the header might be messed up, but I don't have enough collection.db's to know what it should look like exactly. 

Amarok also occasionally crashes on the Mac, usually either just after transition between tracks, or when it updates the collection and there are changes to be made.  Those two might be related, and what I'm perceiving as "transition crashes" might be it trying to update the db.

Not that it should matter, but the Macs are:  2.66Ghz Mac Pro, 2.0Ghz Macbook

Any ideas?

I guess my next step is to create a bunch of sqlite DBs with different characteristics and see if the file header is divergent at some specific point, but that seems like an awful pain.

Any ideas? 

If I get it working again consistently, I'll post the code for the collection browser, promise (it's pretty sparse, but it does the trick for me)

xrayspx wrote:Using sqlite3 from the command line, I get an "unsupported file format" error trying to init the file.  Amarok still reads the file just fine, but I tried deleting the collection and rescanning with the same results.  If I bring down a collection.db from my Linux PC to the Mac, sqlite3 will handle it fine.  I haven't checked to see if I can make Amarok corrupt the file by using it on a Mac.

Your sqlite cli tool must be the same version as your DB. You can't open your v3.3 DB with a v3.2 tool, e.g.

Mark Kretschmann wrote:Your sqlite cli tool must be the same version as your DB. You can't open your v3.3 DB with a v3.2 tool, e.g.

I got it.  Short story is:  Concentrated on the Macbook, since it only had one sqlite3 binary on it, so there was no chance of confusion.  The binary client for sqlite3 was 3.1.3.  It won't read the Amarok DB.  I upgraded, on the webserver, to sqlite3 3.3.8, and it worked.

Link to the working app is here: http://www.xrayspx.com/frames.html I'll post the perl if anyone is interested and I can find a decent place to put that.

Long story:

All of the above.  So it looks as if RangerRick might be packaging sqlite3 3.3.8 or so alongside Amarok?  Maybe one of Amarok's dependencies ships this.  That's about all I can guess, since there is no client executable on this machine except for 3.1.3.  Searching with good 'ole find / on the Mac shows there is a bunch of stuff under /sw/:

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/sqlite3.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.0.8.6.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.0.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/sqlite3
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/sqlite3/libtclsqlite3.dylib
/sw/fink/10.4/stable/main/finkinfo/database/sqlite.info
/sw/fink/10.4/stable/main/finkinfo/database/sqlite.patch
/sw/fink/10.4/stable/main/finkinfo/database/sqlite3.info
/sw/fink/10.4/stable/main/finkinfo/database/sqlite3.patch
/sw/fink/10.4/stable/main/finkinfo/libs/perlmods/dbd-sqlite-pm.info
/sw/fink/10.4/unstable/main/finkinfo/database/javasqlite.info
/sw/fink/10.4/unstable/main/finkinfo/database/javasqlite.patch
/sw/fink/10.4/unstable/main/finkinfo/database/libdbi-drivers-sqlite.info
/sw/fink/10.4/unstable/main/finkinfo/database/pysqlite-py.info
/sw/fink/10.4/unstable/main/finkinfo/database/pysqlite2-py.info
/sw/fink/10.4/unstable/main/finkinfo/database/sqlite.info
/sw/fink/10.4/unstable/main/finkinfo/database/sqlite.patch
/sw/fink/10.4/unstable/main/finkinfo/database/sqlite3.info
/sw/fink/10.4/unstable/main/finkinfo/database/sqlite3.patch
/sw/fink/10.4/unstable/main/finkinfo/libs/perlmods/dbd-sqlite-pm.info
/sw/fink/10.4/unstable/main/finkinfo/libs/perlmods/dbd-sqlite2-pm.info
/sw/fink/10.4/unstable/main/finkinfo/libs/rubymods/sqlite3-rb.info
/sw/lib/qt3/plugins/sqldrivers/libqsqlite.so
/sw/share/mimelnk/application/x-sqlite2.desktop
/sw/share/mimelnk/application/x-sqlite3.desktop
/usr/bin/sqlite3
/usr/include/sqlite3.h
/usr/lib/libsqlite3.0.8.6.dylib
/usr/lib/libsqlite3.0.dylib
/usr/lib/libsqlite3.dylib
/usr/lib/sqlite3
/usr/lib/sqlite3/libtclsqlite3.dylib
/usr/lib/sqlite3/pkgIndex.tcl
/usr/share/man/man1/sqlite3.1


Left out the stuff in my home directory which was mainly dealing with this specific issue.  Reading the .patch files from above they are for v. 3.2.8, but it still seems like a decent bet.

Anyway, thank you for pointing me toward the answer, this link, which showed up on my search for an updated sqlite3 for OSX binary, really honed me in, since it showed a framework shipping with a new sqlite library but no updated client:  http://jtauber.com/blog/2006/11/25/inco ... and_python

I guess this is the only reason I can think of to make my library MySQL.  Still seems like a waste to deal with running MySQL to hold like a couple MB of data max, that's what flatfiles are for...

Thanks again,

xrayspx

Maybe of interest to you: Amarok 1.4.5 (which we've just finished) should compile natively on OSX, without Fink. Give it a try:

http://mark.kollide.net/amarok-1.4.5.tar.bz2

Mark Kretschmann wrote:Maybe of interest to you: Amarok 1.4.5 (which we've just finished) should compile natively on OSX, without Fink. Give it a try:

http://mark.kollide.net/amarok-1.4.5.tar.bz2

Cool, thanks, I'll give it a shot.  Seems to be failing to link in libamarok.la on these machines:
ld: multiple definitions of symbol ___udivdi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_udivdi3. private external definition of ___udivdi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_udivdi3_s. definition of ___udivdi3
ld: multiple definitions of symbol ___umoddi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_umoddi3. private external definition of ___umoddi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_umoddi3_s. definition of ___umoddi3
ld: multiple definitions of symbol ___divdi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_divdi3. private external definition of ___divdi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_divdi3_s. definition of ___divdi3
ld: multiple definitions of symbol ___floatdisf
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_floatdisf. private external definition of ___floatdisf in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_floatdisf_s. definition of ___floatdisf
ld: multiple definitions of symbol ___floatdidf
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_floatdidf. private external definition of ___floatdidf in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_floatdidf_s. definition of ___floatdidf
/usr/bin/libtool: internal link edit command failed
make[4]: *** [libamarok.la] Error 1


I see a few people complaining about building things on OSX specifically with these type of multiple definition errors, I'll try and figure out what my problem is this weekend.

Thanks for the heads-up.

I'll try and figure out what my problem is this weekend.

Found a solution? I have the same problem here.

xrayspx wrote:Cool, thanks, I'll give it a shot.  Seems to be failing to link in libamarok.la on these machines:
ld: multiple definitions of symbol ___udivdi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_udivdi3. private external definition of ___udivdi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_udivdi3_s. definition of ___udivdi3

This means you're trying to mix and match code compiled with g++-3.3 (which only provided a static libgcc on OSX) and g++-4.0.

If you're using fink's KDE libraries, check to see what your Distribution: line in /sw/etc/fink.conf is.  If it's 10.4-transitional, then your KDE was compiled with g++-3.3, and you need to "sudo gcc_select 3.3".  Although, really, you should see "Reminder: "10.4-transitional" Tree Unsupported on August 1st, 2006" on the fink news page.

Otherwise, you need to "sudo gcc_select 4.0" and compile taht way.

RangerRick wrote:If you're using fink's KDE libraries, check to see what your Distribution: line in /sw/etc/fink.conf is.  If it's 10.4-transitional, then your KDE was compiled with g++-3.3, and you need to "sudo gcc_select 3.3".  Although, really, you should see "Reminder: "10.4-transitional" Tree Unsupported on August 1st, 2006" on the fink news page.

Otherwise, you need to "sudo gcc_select 4.0" and compile taht way.

Odd, still getting the same error.  If I check out /sw/etc/fink.conf, I see "Distribution: 10.4", so I specify as above, but it's the same error.  I tried 3.3 just to see what the difference is in errors, and it won't even try to start compiling, which is a good sign.  I did make clean between all attempts.

Unless there's some specific reason not to (stability, etc?) I'll continue to use your excellent Fink builds anyway.  Thanks for the advice, and all the porting work on all these apps.