5061: Music Database doesn't show all Data... (1 Viewer)

[doskabouter]

I can't understand why you have the same sample taking from 0 to over 50 seconds. Could it be a disk problem? Defragmentation? Or a memory problem?

My thoughts exactly, I bet my old n95 phone would be able to return 5000 records in a reasonable time
Or perhaps the marshalling is a bit of a performance killer (didn't yet investigate, but it could be...)
Do we need all the columns (i see a select * done, and I can imagine the calculation time will scale linearly with the number of columns involved)?
Didn't check the logs but I'm assuming no busy retries are done?

If this all fails to get the expected improvement, perhaps we can come up with some pagination scheme? (Although pagination and databases aren't exactly the best of friends...)

And do you really want all those 5000+ entries in one list in mediaportal? that doesn't seem very useful at first sight, but can surely increase the memory usage of your system (possibly starving the sqlite part...)

 

[ajs]

Look for timings, one select, different times ... from ~0 to > 30 ... 5061: Music Database doesn't show all Data...

-- Tapatalk | WBR, ajs

 

[ajs]

For pagination need rework 90% of MP I pass but 5000 items in the list is not that much. But the main problem is why one and the same request is executed at different times, and the difference is at times.

-- Tapatalk | WBR, ajs

 

[joEhSuper]

I can't understand why you have the same sample taking from 0 to over 50 seconds. Could it be a disk problem? Defragmentation? Or a memory problem?

I'll check what I can...

 

[joEhSuper]

I'm not a programmer - only a man who likes MediaPortal and if I'm talking trash please forgive me - just let me know and I stop

Do we need all the columns

If you are talking about the new columns in MusicDatabaseV14, I have to say I also thought about that...
In my point of view, it's the only change (related to that) I can see from MP1.26 to MP1.27. And in MP 1.26 all works fine. Because of that I doubt problems with harddisk or memory.

I think my Laptop should be able to handle this...

And do you really want all those 5000+ entries in one list in mediaportal?

In general I absolutly agree - and if it's not possible to handle I can use other MusicViews of course
But also when I set Index A-Z at first level (to not get that long lists), the error occurs also in subfolders

 

[joEhSuper]

Logs for Test 03 -->
Logs for Test 04 follow in the evening...

 

[ajs]

Logs for Test 03 -->

[2021-01-13 07:36:34,221] [Log    ] [MPMain   ] [DEBUG] - SQLiteClient: ReadpVm (-15,9211489) Exceeded sampling time, may not have received all the data.

 

[ajs]

I think my Laptop should be able to handle this...

Windows 10 x86? Maybe try install Windows 10 x64?

 

[ajs]

Didn't check the logs but I'm assuming no busy retries are done?

No retries, I've reviewed many projects on GitHub, no one has a sampling time limit, only Mediaportal. This is good on the one hand, and bad on the other. We work fast, but sometimes not all the way through.
I filled a music database with random records, the number of 20000 records, and ran the same query in SQLiteExpert. The sampling time with mapping is about 50ms. As confirmed by the log in Mediaportal. But why the time can increase, I do not know. Maybe we should clean the lists in SQLiteClient after the fetching or something like that.

 

[ajs]

@doskabouter if we change this: MediaPortal/MediaPortal-1
from:

internal void ReadpVm(string query, SQLiteResultSet set1, ref IntPtr pVm)

to:

internal SQLiteResultSet ReadpVm(string query, ref IntPtr pVm)

Could this help?