Not loading custom vfs file

[Fuzzy]

I'm really not sure if this is really a phoenix issue, but I just came across this while re-installing my main client (hardware upgrades). Clean windows install, clean sagetvclient install. Upgraded STV, and installed weather plugin as prompted. then installed gemstone UI Mod, which in turn installed phoenix, and obviously a lot more. Gemstone loads up fine, and functions relatively fine - however, the gemstone vfs views are not being loaded in. The x-gemstone-vfs.xml file resides in C:\Program Files (x86)\SageTV\SageTV\STVs\Phoenix\vfs like it always has, but none of those views are present. installing BMT on the client has the views missing there as well. no reference to it is showing up in phoenix.log.

So, first guess: Phoenix is not looking for new xml file sin STVs/Phoenix/vfs anymore -> move the file to userdata/Phoenix/vfs and restart - no change.

Pour more detailed through phoenix log, and find a line mentioning that the cache is not changed, so it reimports that - apparently in lieu of searching for new vfs xml's. I delete the cache xml file from userdata/Phoenix/cache, restart the client, and it brings in the gemstone xml file perfectly fine.

Shut it back down, and move the gemstone file back to the STV/Phoenix/vfs location, and again, it doesn't import it, saying the cache is unchanged.

Delete the cache file again, and it works fine.

So, I'm thinking there's a bug in phoenix regarding the vfs cache file, and new xml files being ignored - not sure if this is a new or recently changed process.

[stuckless]

This is a bug... although not sure why it affected your gemstone view. I did have Jusjoken test this before I shipped the changes, and it appeared to have worked... but I guess not.

I verified that it was doing this for the bmt plugins
http://forums.sagetv.com/forums/showthread.php?t=60075

but I didn't think it would affect gemstone.

When phoenix starts, it is supposed to check the timestamps of ALL vfs files against the cached version, and if ANY of the files are newer, then it rebuilds the cached file, and then loads that file. That's obviously not working

This change happened in the last build, if I recall. There are some timing issues in how Phoenix resolves filters, sources, etc, that this build fixes... but breaks this.

[jusjoken]

I never tried a clean Gemstone install so I assume that's the issue that is not being handled with the cache check. Any manual update to the gemstone vfs according to my testing will force the vfs cache to rebuild.

k

[Fuzzy]

Yeah, perhaps this is coming out of doing a fresh install and direct install of gemstone. So, the first time phoenix is loaded, both vfs files are already there... not sure though, really.

[stuckless]

Originally Posted by jusjoken

I never tried a clean Gemstone install so I assume that's the issue that is not being handled with the cache check. Any manual update to the gemstone vfs according to my testing will force the vfs cache to rebuild.

k

Originally Posted by Fuzzy

Yeah, perhaps this is coming out of doing a fresh install and direct install of gemstone. So, the first time phoenix is loaded, both vfs files are already there... not sure though, really.

My "fix" for this will be to remove the cache check and rebuild the file anytime it is asked. It's a quick process anyways...

[Fuzzy]

Originally Posted by stuckless

My "fix" for this will be to remove the cache check and rebuild the file anytime it is asked. It's a quick process anyways...

I'd agree - I'm not sure what prompted the cache file anyways - I can't imagine the vfs building is very intensive.

[stuckless]

Originally Posted by Fuzzy

I'd agree - I'm not sure what prompted the cache file anyways - I can't imagine the vfs building is very intensive.

What "prompted" it was that there are timing issues in how sections of the VFS are processed. ie, if you override a core view/filter/group, etc, from another vfs file, then any core views that relied on that group/filter would still use the original and not the new one.

Since very few people (aside from myself) acutally create custom views (oe extend the behaviour of existing views, as I do) it's not a "bug" that would have been known to many people.

The solution was to process the vfs and resolve all the views/groups/filter, etc, and re-write the vfs into a single vfs file, and then load that file, and all the timing issues go away. Since this is an intermediate file, I decided to cache it. I agree... it didn't need to be cached... it was just easy to do so... and hard to do it right, apparently

[Fuzzy]

Originally Posted by stuckless

What "prompted" it was that there are timing issues in how sections of the VFS are processed. ie, if you override a core view/filter/group, etc, from another vfs file, then any core views that relied on that group/filter would still use the original and not the new one.

Since very few people (aside from myself) acutally create custom views (oe extend the behaviour of existing views, as I do) it's not a "bug" that would have been known to many people.

The solution was to process the vfs and resolve all the views/groups/filter, etc, and re-write the vfs into a single vfs file, and then load that file, and all the timing issues go away. Since this is an intermediate file, I decided to cache it. I agree... it didn't need to be cached... it was just easy to do so... and hard to do it right, apparently

Makes sense. So is this intermediate file references on every vfs lookup, or is it used from memory? if so, it seems like if it is being used from memory, it really doesn't need to be rendered down to a file, and you could load in the vfs files on startup (or view refresh), and just work from memory that way.

Somewhat related, but not really - is there a 'easy' way to have the vfs system managed via server side files alone, so the vfs files don't have to be duplicated to each client?

[stuckless]

Originally Posted by Fuzzy

Makes sense. So is this intermediate file references on every vfs lookup, or is it used from memory? if so, it seems like if it is being used from memory, it really doesn't need to be rendered down to a file, and you could load in the vfs files on startup (or view refresh), and just work from memory that way.

Yeah, I don't need to write it back to the filesystem, but I do, because it's the only real way that I can inspect the vfs entries and verify that things are gettnig loaded. ie, if you ceck that file, you'll see that in the header, I list ALL the files that contribute to this intermediate file. I can probably add an option to NOT create the file.

Somewhat related, but not really - is there a 'easy' way to have the vfs system managed via server side files alone, so the vfs files don't have to be duplicated to each client?

There is no "easy" way, but I see what you saying... on each client, you need to have ALL vfs files if you want to use that view. Something I can look into.