Strange database problem -- pvrx2 not seeing updates, EWA and Config.exe are.

[86atc250r]

I'm probably missing something very simple here, but here's my scenario.

I recently moved to win7 from XP. I copied my GBPVR folder to the new win7 installation, in the usual place.

I installed GBPVR over top of the copied files. After a little config, all seemed well.

Since then, I've recorded a couple programs - they don't show up in the recordings section, however, they have been saved. I have also added a tuner, and added a channel to my lineup -- it does not show up in pvrx2 either. EPG also appears to not be updating.

Now the strange part --- the missing recording and the missing channel show up in EWA. EPG is good in EWA. When I check config.exe, my tuner and channel show up there exactly as expected. It's almost as if pvrx2 is reading a different database than config.exe or EWA.

Further testing - I broke out process monitor to see what database file both config.exe and pvrx2.exe are using - both are using the gbpvr.db3 database on the correct drive and in the correct folder. I also ran a admin utility for SQLite so I could manually inspect the database contents - it does not appear to have the channel or the tuner I have configured.

So --- where the heck are EWA and config.exe getting their (correct) data? Why isn't PVRX2.exe seeing the correct data? Why don't my channel and tuner show up in gbpvr.db3?

Surely I'm missing something stupid here...

[martint123]

Could be Win7 protection? Have a look at http://forums.gbpvr.com//showthread.php?...ng-to-file
This one for Vista http://forums.nextpvr.com/showthread.php...post352707

The o/s being to clever for its own good! (npvr improved things by moving data files away)

Martin

[86atc250r]

Good call - I just had to set pvrx2 to run as an administrator. WTF is win7 up to, to cause that sort of problem? I disabled UAC for good measure while I was at it.

[johnsonx42]

UAC is the culprit. When it's on, and you make changes to files under the Windows and Program Files structures as a regular user, it puts your copy of the files into a virtual store directory; after that regular users see the files one way, and adminstrator/system see the files another way. So you can slowly go insane trying to understand why you see the files correctly, yet the application keeps doing something else.

With UAC off, you'll have no further trouble. There's been (sometimes heated) discussion about this off and on, but I think UAC is almost always more hassle than it's worth for anybody but 'regular' users. Regular users don't do anything to run afoul of UAC most of the time, and benefit from it's protection. While power-users know how to deal with UAC, they're also the ones who have the least to gain from it's constant meddling. It's always the in-between users who know just enough to be dangerous we have to worry about.

The other solution is to grant full access to the c:\program files\DevNZ directory to your regular user account, and also delete the c:\users\YOUR USER\AppData\Local\VirtualStore\Program Files\DevNZ directory.

[86atc250r]

Excellent - Thanks for the response. For me, UAC seems only to be a bunch of pain and suffering. I've managed quite well for years on XP without it & think I will be best served to turn it off for my future win7 and beyond systems. What you described is exactly what was going on.

One thing that still confuses me though, is I watched the database access with Process/File Monitor and it sure showed it accessing the correct database file, also, when I queried the database file directly, I got the bogus results -- I guess the windows API must be doing it's "magic" at a lower level than process monitor is watching & giving you access to the virtual store file even though you directly selected the file to connect to --- neat..... That's a level of pain and suffering I certainly do not need or want.

[martint123]

I think it works a bit like a sandbox (which I suppose it is) where reads come from the original data source, but writes go to a separate area - all invisible at application level.