Bug If I use sqlite data store I can not share playstate

 
4 supporters

Hi Guys,

I have just updated to build 1662 last night upon receiving a new media centre pc for my bedroom (wanted to install a new build across all 3 htpc’s). There seemed to be a few more dll files to install in the mediaBrowser\bin\release folder and upon launching MB I received a message asking if I wanted internet providers etc, as if it was the first time I had used MB. (also wanted to rebuild display views etc)

My new machine in the bedroom is running via wireless N and it did take quite some time to populate the image cache. The problem I seem to be having is that I can’t get the playstate folder sync'd anymore. I had this working last week with my server/main htpc by simply editing the config userpath setting.

Has this been changed in the new build guys?

 
votes newest oldest
 
  • Created:over 3 years ago

Yerp no shared play state with sqlite yet, I still need to implement that. If you use the old item cache you will get shared playstate.

Will convert this to a bug so its tracked.

 
 
  • Created:over 3 years ago

Thanks for the reply Sam,

Is there a way in which I can select which item cache to use (old/new)?

 
 
  • Created:over 3 years ago

set EnableExperimentalSqliteSupport to false … its false by default (in the configuration file)

 
 
  • Created:about 3 years ago

Hey Sam. I was wondering if you were any closer to a shared playstate and display settings solution? Jon got me started with a simple table replace to at least clone the playstates from one machine to another. This got me to thinking about SQLite and I started reading up on the little engine and started tinkering with the tables, etc etc. At any rate I was about to script up a really ugly hack to sync the playstate table across 3 databases and didn’t want to bother(and take the risk of corruption) if you were working on something.

-Sinjen

 
  • hmmm I will see if I get a chance, just got back today – sam about 3 years ago
  • Thanks Sam. Hope your vacation was awesome :) Btw, I didn’t mean I was about to release an ugly hack. I was just doing this for myself, but I won’t bother if even rudimentary playstate sharing is coming anytime soon. – sinjen about 3 years ago
 
  • Created:about 3 years ago
  • Modified:about 3 years ago

How about if I simply pull display state out of the sqlite DB, this would enable sharing right away and is not such a big change?

Ofcourse this will be a breaking change so you will have to repopulate playstate !

 
  • If by “display state” you mean watched status. I think that would work. Would there be a performance hit of any kind that you can see? – sinjen about 3 years ago
  • I think this wouldwork Sam, I can’t see the watched status having a great impact on the cache speed from a sqlite perspective. – tylor about 3 years ago
 
  • Created:about 3 years ago
  • Modified:almost 3 years ago

OK I just committed a fix, for an added bonus it migrates the old data out of sqlite

Data Migration never happened, I made some schema changes that invalidated the cache.

 
  • To use the new change, we just follow the old instructions for sharing playstate? Also, does the change include display/view settings? – sinjen about 3 years ago
  • display / view settings are not included … and yes, old instructions should work – sam about 3 years ago
  • so that means that the display settings are still lost after the upgrade to Cronos since the cache.db is being removed so it can be rebuild, right? – birkoff about 3 years ago
  • hmm did I break the schema in chronos somewhere ? I would like to get a clean upgrade to work – sam about 3 years ago
  • well ebr mentioned in this FR that the cache will go goofy. There’s also another topic somewhere where he stated that the cache would be cleared during the upgrade. Can’t find it right now though. – birkoff about 3 years ago