Reply to thread

Message: <blockquote data-quote="MJGraf" data-source="post: 1028491" data-attributes="member: 17886">And here is the proof...What I did is replace this code in MediaLibrary.Search(MediaItemQuery query, bool filterOnlyOnline)[CODE]      IList<MediaItem> items = cmiq.QueryList();[/CODE]with this code[CODE]      var sw = System.Diagnostics.Stopwatch.StartNew();      IList<MediaItem> items = cmiq.QueryList();      sw.Stop();      ServiceRegistration.Get<ILogger>().Debug("MediaLibrary: Search time {0} for query {1}", sw.Elapsed, query.ToString());[/CODE]Restarted the MP2 Server with my 1.7GB test library. Started the MP2 Client on my laptop and entered the audio section ("large list" was still selected). First observation was that this did not result in a log entry. Apparently entering the audio section uses some other MediaLibrary method to query its media items. Then I entered the first album shown (the one with 11 tracks each with an embedded cover of 49KB). And this was in my Server.log:So querying those 11 MediaItems with 11x49KB = 539KB of coverart including reading all the data from the database file into RAM and composing a list of 11 MediaItems took roughly 38ms. Not really bad...I went back with ESC and now entered the Queen/Innuendo album (remember: 12 tracks with 12x2,8MB=33,6MB coverart). Now I actually measured how long it took until the 12 tracks were displayed on my Laptop: 59 seconds!!! And this was already with "large list" (i.e. VirtualizingStackPanel)! But how much of this was caused by the database? Hold your breath:Just 228,6ms!!! Again: This is including executing the query itself, transferring all the data from disk into RAM and composing our List of MediaItem objects! If we just calculate the raw transfer speed ignoring the fact that during these 228,6ms we have also executed the query and copied the result a few times in RAM, then we get 1000/228,6*33,6MB=147MB/sec! This result is perfectly reasonable with my Crucial C300 SSD and of course it would be slower with a standard harddisk. But to be honest I doubt we would really be faster if our images were saved as files in the filesystem...And it gets even better - I left the screen with ESC and again entered Queen/Innuendo on my client and we can see that the SQLiteDatabase's cache works:Now we're talking about 111,3ms - and a "transfer" speed of about 300MB/sec. I don't think this is real disk (or SSD) transfer speed but the data was already in RAM due to the fact that we executed exactly the same query a minute before, but this is exactly what the SQLite cache is supposed to do...The remaining question is: If it took 59 seconds to open the queen/innuendo album in the MP2 Client and only 0.2 seconds were caused by the database - what causes the remaining 58.8 seconds?!? Well, in my case I'm sure that most of this is caused by my very slow network connection. While my laptop has 802.11n, my server is usually used as singleseat MP1 Server and client therefore doesn't need a fast network connection and as a result only has 802.11g (i.e. theoretically a maximum of 54MBit/sec, realistically much slower...). So my guess is that transferring those 33,6MB over this lan connection takes most of the 58.8 seconds. Furthermore, my laptop only has quite an old Mobile Intel 4 Series Express graphics chip and if we really load the full 33,6MB image data into the graphics card and let it downscale, this may also take some time...From my point of view in my personal case (which is only a test case - when I use MP2 in a real case, it is all single seat) there is not much we could improve from an MP2 perspective. Maybe it makes sense to introduce something like a "low res mode" for slow networks / computers in which we downscale image data to a reasonable size before transmitting it to the client. But this is really not first priority...So my conclusions for now are as follows:<ul> <li data-xf-list-type="ul">Storing images in the SQLiteDatabase is not a problem at all - even when the images are nearly 3MB in size (which should be enough for every use case including high res backdrops, etc.). So @[USER=48495]morpheus_xx[/USER] I don't think it would slow down the system if you want to store your FanArt directly in the database. But I think the bigger problem there is that an "Album" is not a MediaItem in our current structure - neither is an "Artist", but this is another story.... </li> <li data-xf-list-type="ul">From my point of view I can try to tweak the SQLiteDatabase to save some additional ms. But currently I'm not sure if it's worth the effort. There are things that cost much more time and need a speed-up more urgently - such as implementing a VirtualizingWrapPanel or what @Valks is doing regarding virtualization on the database access level. @[USER=109222]Lehmden[/USER] Of course I will have a look at your logs and do some further testing as soon as you are high-speed-DSL-connected and can give me some SQLDebug.Logs. Maybe it is completely different on a regular hard disk instead of an SSD. But until then I think I will not spend more time on this. There are more important things...</li> </ul>And once again: Any comment is welcome <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />Michael</blockquote>

Verification