feb 4 build
fresh scan
other sections work fine. can enqueue everything via albums (may rule out problem file)
log follows
Quote:06-02-2006 00:22:09 info loading skin file: mymusicnav.xml
06-02-2006 00:22:09 debug cguimediawindow::getdirectory ()
06-02-2006 00:22:09 debug parentpath = []
06-02-2006 00:22:09 debug current m_vecpathhistory:
06-02-2006 00:22:09 debug 00.[]
06-02-2006 00:22:12 debug cguimediawindow::getdirectory (musicdb://4/)
06-02-2006 00:22:12 debug parentpath = []
06-02-2006 00:22:12 debug cutil::getmatchingshare, testing original path/name [musicdb://4/]
06-02-2006 00:22:12 debug cutil::getmatchingshare, testing url [musicdb://4/]
06-02-2006 00:22:12 debug cutil::getmatchingshare, comparing url [musicdb://1/]
06-02-2006 00:22:12 debug cutil::getmatchingshare, comparing url [musicdb://2/]
06-02-2006 00:22:12 debug cutil::getmatchingshare, comparing url [musicdb://3/]
06-02-2006 00:22:12 debug cutil::getmatchingshare, comparing url [musicdb://4/]
06-02-2006 00:22:12 debug found matching bookmark at index 3: [musicdb://4/], len = [12]
06-02-2006 00:22:12 debug loading fileitems [z:\44e615ab.fi]
06-02-2006 00:22:12 debug cmusicdatabase::getsongsnav() query: select * from songview
06-02-2006 00:22:24 error cmusicdatabase::getsongsnav() failed
06-02-2006 00:22:25 debug cguimediawindow::getdirectory ()
06-02-2006 00:22:25 debug parentpath = []
06-02-2006 00:22:25 debug current m_vecpathhistory:
06-02-2006 00:22:25 debug 00.[]
06-02-2006 00:22:25 info loading skin file: dialogok.xml
06-02-2006 00:22:25 debug udpclient tx: 1337271 -> 'kai_client_get_metrics;'
06-02-2006 00:22:25 debug udpclient rx: 1337286 <- 'kai_client_metrics;speakeasy.net;not yet;70.66.1.88;2212;7.0.0.4;kaistation;mineiro;br0;1;0;0;0;0;0;0;libpcap;n/a;0;0;0;0;'
how large is your database? the xbox has a limited amount of memory, and getting all the songs out the database will fail on a large database when the xbox runs out of memory. (and by large, i mean > 15,000 items which i can attest works.)
about 8100+ entries. but i'm running with 10megs less ram than most as milkdrop is running while ia query. perhaps that is the issue
maybe. try it without anything else running. it's been a few weeks since i tried, but i was able to open songs off the root with about 15,000 items. i can retest tonight for confirmation.
i think this is where the problem is in database.cpp
m_pds->exec("pragma cache_size=16384\n");
maybe this should be a smaller number like 10000 since it's the number of pages and each page uses 1.5k per page. not sure how this will affect the perfomance of the db functions?
i saw your comments kraqh3d and your were looking for 16k so that means 10 or 11 pages.
http://www.sqlite.org/pragma.html
thanks for all the hard work!!!
i've also noticed that the 'this database is empty switch to files view' no longer works. when you open albums, genres, songs, etc you get invalid path errors.
alterior : will give it a try thanks
alterior,
yes, changing the cache size will free up some memory. i'm not really sure why thats pushed up to 16384. it will impact performance but probably not that much.
loto_bak,
got a log of these errors? i dont know what you're refering to.
sorry,
you know the situation where if the user does not have a library, the library listcontrol displays a message insted of albums/artists/songs etc. this message states the user should go to files view and scan songs. at this time if no database exists albums/artists/songs are still displayed. if you select any of them you simply get an 'invalid path' error.
here is a log of starting with no db and the attempting to enter albums then artists.
Quote:09-02-2006 22:50:00 info loading skin file: mymusicnav.xml
09-02-2006 22:50:01 info create artist table
09-02-2006 22:50:01 info create album table
09-02-2006 22:50:01 info create genre table
09-02-2006 22:50:01 info create path table
09-02-2006 22:50:01 info create song table
09-02-2006 22:50:01 info create albuminfo table
09-02-2006 22:50:02 info create albuminfosong table
09-02-2006 22:50:02 info create thumb table
09-02-2006 22:50:02 info create exartistsong table
09-02-2006 22:50:02 info create extragenresong table
09-02-2006 22:50:02 info create exartistalbum table
09-02-2006 22:50:02 info create exgenrealbum table
09-02-2006 22:50:03 info create exartistsong index
09-02-2006 22:50:03 info create exgenresong index
09-02-2006 22:50:03 info create exartistalbum index
09-02-2006 22:50:04 info create exgenrealbum index
09-02-2006 22:50:04 info create album index
09-02-2006 22:50:04 info create genre index
09-02-2006 22:50:04 info create artist index
09-02-2006 22:50:05 info create path index
09-02-2006 22:50:05 info create song index
09-02-2006 22:50:05 info create song index1
09-02-2006 22:50:05 info create song index2
09-02-2006 22:50:05 info create thumb index
09-02-2006 22:50:06 info create albuminfo trigger
09-02-2006 22:50:06 info create song view
09-02-2006 22:50:06 info create album view
09-02-2006 22:50:06 debug cguimediawindow::getdirectory ()
09-02-2006 22:50:06 debug parentpath = []
09-02-2006 22:50:06 debug current m_vecpathhistory:
09-02-2006 22:50:06 debug 00.[]
09-02-2006 22:50:06 debug udpclient tx: 16101 -> 'kai_client_caps;013;'
09-02-2006 22:50:08 debug cguimediawindow::getdirectory (musicdb://3/)
09-02-2006 22:50:08 debug parentpath = []
09-02-2006 22:50:08 debug cutil::getmatchingshare, testing original path/name [musicdb://3/]
09-02-2006 22:50:08 debug cutil::getmatchingshare, testing url [musicdb://3/]
09-02-2006 22:50:08 debug cutil::getmatchingshare, comparing url [musicdb://1/]
09-02-2006 22:50:08 debug cutil::getmatchingshare, comparing url [musicdb://2/]
09-02-2006 22:50:08 debug cutil::getmatchingshare, comparing url [musicdb://3/]
09-02-2006 22:50:08 debug found matching bookmark at index 2: [musicdb://3/], len = [12]
09-02-2006 22:50:08 debug loading fileitems [z:\5aa145ae.fi]
09-02-2006 22:50:08 debug cmusicdatabase::getalbumsnav() query: select * from albumview where albumview.stralbum != ""
09-02-2006 22:50:08 debug cguimediawindow::getdirectory ()
09-02-2006 22:50:08 debug parentpath = []
09-02-2006 22:50:08 debug current m_vecpathhistory:
09-02-2006 22:50:08 debug 00.[]
09-02-2006 22:50:08 info loading skin file: dialogok.xml
09-02-2006 22:50:09 debug cguimediawindow::getdirectory (musicdb://2/)
09-02-2006 22:50:09 debug parentpath = []
09-02-2006 22:50:09 debug cutil::getmatchingshare, testing original path/name [musicdb://2/]
09-02-2006 22:50:09 debug cutil::getmatchingshare, testing url [musicdb://2/]
09-02-2006 22:50:09 debug cutil::getmatchingshare, comparing url [musicdb://1/]
09-02-2006 22:50:09 debug cutil::getmatchingshare, comparing url [musicdb://2/]
09-02-2006 22:50:09 debug found matching bookmark at index 1: [musicdb://2/], len = [12]
09-02-2006 22:50:09 debug loading fileitems [z:\5e605819.fi]
09-02-2006 22:50:10 debug cmusicdatabase::getartistsnav() query: select * from artist where (idartist in (select distinct song.idartist from song) or idartist in (select distinct exartistsong.idartist from exartistsong)) and artist.idartist<>1 and artist.strartist != ""
09-02-2006 22:50:10 debug cguimediawindow::getdirectory ()
09-02-2006 22:50:10 debug parentpath = []
09-02-2006 22:50:10 debug current m_vecpathhistory:
09-02-2006 22:50:10 debug 00.[]
09-02-2006 22:50:10 info loading skin file: dialogok.xml
it appear that xbmc is creating the db as soon as the user enters mymusicnav.xml (library view)
regarding the songs listing. there does not appear to be any memory issues. i can reproduce it easily.
have you been able to test?
ok. i see it whats wrong. this is because of how most everything happens in a new media window base class. it doesnt handle the specific case of the empty database anymore and uses the general error of "path not found or invalid".
(kraqh3d @ feb. 10 2006,02:36 Wrote:i'm not really sure why thats pushed up to 16384. it will impact performance but probably not that much.
this increases performance when scanning (doing lots of inserts into the database) measurable. it should be no problem to increase it only when scanning and lower it after scanning it done.
greets
bobbin007
bobbin,
thanks for the clarification on the cache size. re: the db error message. i was thinking of defining a new share type of share_type_db to identify the musicdb:// urls so that the old error message could be restored. any issues?
i did a quick fix for the message issue. i wonder why this worked before. it shouldn't, because the base class call opens the database and the displayemptydatabasemessage() is called with a database function as a parameter before the database is opened. :nuts: mystery of software
but don't forget the issue with the large song list of over 13k that originally started this thread, is due to the
m_pds->exec("pragma cache_size=16384\n");
it should be
m_pds->exec("pragma cache_size=16\n");
since you wanted 16k according to the source comments, and each page in the cache_size param is 1k on disk and 1.5k in memory.
alterior
unfortunatly that fix does not help. it does not seem to be a memory issue
no one has confimed or denied the bug exists in their box. could someone please check to see if they experiance the same issue?
i can execute the query without issue in sql lite 3 on the pc. (select * from songview)
alterior, that has nothing to do with it.