In-Progress Increasing Performance on Large Collections (Especially Album Artist)

[chessdragon136 677]

Ok i think i'm following you

 

I'll push out a new version in 20 mins or so

[ebr 14910]

People processing on the server is relatively slow because we have to calculate all of the items they belong to on the fly.  This is an area tagged for improvement in the future but it will take quite a bit of re-architecting stuff I believe.  So, clients do have to be very careful about trying to bring back large blocks of people (actors, artists, whatever).

[ginjaninja 533]

People processing on the server is relatively slow because we have to calculate all of the items they belong to on the fly.  This is an area tagged for improvement in the future but it will take quite a bit of re-architecting stuff I believe.  So, clients do have to be very careful about trying to bring back large blocks of people (actors, artists, whatever).

 

 

in my experience speed of album artists is the people one with highest priority..common client interfaces under common use are affected...waiting for cast and crew..not so much of an issue..much less time critical and less frequently used...but album artists (i use) all the time..

 

the roku's design of splitting into letters is the most performant (speed and useability) of all the clients...imo..currently

[chessdragon136 677]

Yeah well I was hoping the chunk loading would help more but I will implement an A to Z view. I'll leave the chunk coding in and bring the chunk size down to 100 a pop or make it a device option so users with faster servers can load larger chunks.

[ebr 14910]

MBC also uses letter folders to reduce the size of people result sets.

[chessdragon136 677]

 

[FrostByte 5049]

Does this mean a new version is going up soon then?

[CBers 6771]

Does this mean a new version is going up soon then?

Looks good Chess.

[chessdragon136 677]