RAL not refreshing in real time on new content

[ginjaninja 538]

3.0.96 - MBC

Version 3.0.5076.20161 - MB3

All content stored on local hdds accessed via unc on htpc.

4 TV UNCs make up TV Collection, 22000 episodes

 

Same Symptoms on XBOX and HTPC, default and subdued theme.

Tested with TV Content and 'Last Added' RAL.

 

steps to reproduce

Launch MBC

Move to TV Collection- TV RAL Appears

Run TVRename - a utility to move content into the collection firstly as mediafile.tvrename and then renamed to mediafile.normalextension.

MB3 Server detects new content

MBC often gives a new item notification (not always) but rarely initiates a RAL refresh (but does sometimes)

 

Other symptoms

If i have 2 MBC sessions loaded on xbox and htpc, then the symptoms are mostly similar in frequency but not identical for the same import of content (XBOX may get new item notification but no RAL refresh, HTPC might outwardly exhibit nothing)

 

Steps to fix

exit MBC and reenter, initiates a RAL rebuild.

 

In this case,

american dad S10E05 and Never MInd the Buzzcocks S27E10 added 16:17 local time to collection by tvrename,

MB3 server picks up new content almost immediately

New item notification for NMTB almost immediately

no RAL refresh on xbox

 

FWIW time on MBC log is not 24hrs.

 

https://dl.dropboxusercontent.com/u/84611964/RAL/MBClassic-26112013fbea858f8f004613a1e4d663ab36a47b.log

https://dl.dropboxusercontent.com/u/84611964/RAL/server-63521020799.log

[ginjaninja 538]

@@ebr

Hi Ebr, any thoughts on this one? Is it expected that the new content would precipitate a RAL rebulld?

 

Anyone else finding ral rebuilds, working reliable well, for new content in tv collections.

ty

[ebr 14944]

I think movie content works pretty well.  TV is still a bit sticky due to the multiple levels and the fact that things are added at the third level usually.  MBC doesn't load your entire library until you go somewhere that makes it necessary and, when the server notifies me of a change, it tells me the ID of the item that was added and the ID of the folder containing it.

 

BUT, with TV, the folder that contained an episode is still two levels down in the hierarchy and it may not be loaded into MBC at the time.  So, I cannot determine which collection this item that changed belonged to and know what to refresh.

 

I am looking into this more and may end up just forcing a complete refresh of all top level RALs whenever anything is added/removed.

[ginjaninja 538]

thanks for feedback. 

 

An idea....Does the client have to take so much responsibility?

 

Might it be possible for the server to maintain common RALs  as "database 'views'" created via 'optimised/fast' stored procedures on the server.

Ie make it the servers responsibility to maintain the RAL (The view content and a version number for the view)

 

Accuracy benefits

the server has the exact awareness of change (location/collection and time), as it has had to instance the change in the 1st place for new content ingestion.

 

Efficiency Benefits

the server has the horsepower to regenerate views. Clients need only check the version number of the view, and if the version is later, retrieve the view content (and not have to calculate content).

Multiple clients would probably share the common views/RALs as the user requirements are mostly? the same across clients.

If the client / user requirements are not the same in ALL cases then perhaps the server could provide  a client api to support registration of bespoke RALs (bespoke stored procedures).

 

UI Benefits

If the server is doing the leg work in the background, then presumably the client experience / ui would be more fluid, as the client would  never have to pause whilst calculating.

The server can be as slow as it wants/needs to be to generate the RAL views, without impacting the real time client experience.

 

I find xbox crashes are much more frequent when moving between the RALs in the UI, rather than general browsing away from ehs, so perhaps there is an opportunity here as well to take a load off the client.

 

(idle musings of a non developer with no clue of how MB3 really works...)

[ebr 14944]

I suppose if the collection id were included it would help. However MBC may be the only thing that will ever care and I can just brute force it.

[Luke 37151]

thanks for feedback. 

 

An idea....Does the client have to take so much responsibility?

 

Might it be possible for the server to maintain common RALs  as "database 'views'" created via 'optimised/fast' stored procedures on the server.

Ie make it the servers responsibility to maintain the RAL (The view content and a version number for the view)

 

Accuracy benefits

the server has the exact awareness of change (location/collection and time), as it has had to instance the change in the 1st place for new content ingestion.

 

Efficiency Benefits

the server has the horsepower to regenerate views. Clients need only check the version number of the view, and if the version is later, retrieve the view content (and not have to calculate content).

Multiple clients would probably share the common views/RALs as the user requirements are mostly? the same across clients.

If the client / user requirements are not the same in ALL cases then perhaps the server could provide  a client api to support registration of bespoke RALs (bespoke stored procedures).

 

UI Benefits

If the server is doing the leg work in the background, then presumably the client experience / ui would be more fluid, as the client would  never have to pause whilst calculating.

The server can be as slow as it wants/needs to be to generate the RAL views, without impacting the real time client experience.

 

I find xbox crashes are much more frequent when moving between the RALs in the UI, rather than general browsing away from ehs, so perhaps there is an opportunity here as well to take a load off the client.

 

(idle musings of a non developer with no clue of how MB3 really works...)

 

It has more to do with the way mbc is built that makes it a challenge. It has to keep some of this data in memory for themes to access it, and that makes it tricky to refresh. Our other clients pull everything fresh on every screen so it's much easier.

 

Ebr, we could improve our change messages to contain more information if that's what you need.