cancel manual recording?

[Ommina]

Interestingly, I was doing just that when the reply notice popped up.

Sadly, it didn't work as well as I had hoped. In fact, "hissy fit" probably comes closer. This is from "config.exe.log":

2008-08-18 22:22:30.787 ERROR [1] FATAL UNHANDLED EXCEPTION:: System.IO.FileLoadException: Could not load file or assembly 'System.Data.SQLite, Version=1.0.30.1, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'System.Data.SQLite, Version=1.0.30.1, Culture=neutral, PublicKeyToken=db937bc2d44ff139'
at GBPVR.Backend.Common.xcbcfc48b9705b7a2..ctor()
at GBPVR.Backend.Common.xcbcfc48b9705b7a2.x479a7b07c9d5bd70()
at Config.xfd6951461fe46d87..ctor()
at Config.xfd6951461fe46d87.xfb409e85bd292293()

=== Pre-bind state information ===
LOG: User = OMMINA\Pvr
LOG: DisplayName = System.Data.SQLite, Version=1.0.30.1, Culture=neutral, PublicKeyToken=db937bc2d44ff139
(Fully-specified)
LOG: Appbase = file:///C:/Program Files/devnz/gbpvr/
LOG: Initial PrivatePath = NULL
Calling assembly : GBPVRBackendCommon, Version=1.0.3069.9823, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: System.Data.SQLite, Version=1.0.30.1, Culture=neutral, PublicKeyToken=db937bc2d44ff139
LOG: Attempting download of new URL file:///C:/Program Files/devnz/gbpvr/System.Data.SQLite.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

PVRX2 also gives a "system.io.fileloadexception", but no logging.

My plugin has also run into the same error, but only three times in the past eight months. I'm going to try changing it to the new version of the wrapper, but when the error shows up that infrequently, it could be a long while before we'll know if it did any good...

[Ommina]

Follow-up -- I ran the ADO.NET Provider test.exe that is included with the wrapper distribution zip against the current (2006) version of the wrapper, and it failed the Multithreading test with the "database is locked" error. In my case, I am rolling some separate threads, which may very well be why the error shows up so infrequently.

[pBS]

think limiting to 1 cpu would help? never had these problems before, and i used to have much more epg data and recordings...but cancelling has been screwy for several vers.
[just never saw so many 'busy db' situations]

i tried recording out of process, and not...same
seemed to start once i went to a true dual-core so thought that may be a clue..
will try to fine the setting for forcing single processor and see if that helps..

[sub]

No, I dont think it'd relate to that or we'd see a lot more reports of it. I've also been running it on dual core machines for the last three years or so (AMD and Intel) and I've not seen this problem here.

Very few people have reported this problem, but those seemed to get it often. I'm guessing they either do something a slightly different way to most people and there is a specific set of steps that lead to this problem, or some of the plugins they're using lead to the problem happening.

[pBS]

what's required to cancel manually? can i do it from db alone?
assuming i need the system to 'see' that changes have been made in db after adjustment..
[as a workaround till fix is found]

this seems to effect all db writes,[long pauses after] so a resolution is really needed..
hopefully i'll get a chance to do a fresh build to see where it starts happening..
[i have an identical MB,etc]
hope it's not an xpMCE thing.
i wonder if there are any hotfixes for ADO that i'm missing? [running 2005 with rollup]

p.s. plugin dir empty, blue skin, comskip from parallelproc and ffmpeg snap from postproc[tried without both, same] hip with mce remote.

last time i did a fresh win/gb install, it was a bit faster but you could still see the delay..and quickrecs were slow on third instead of second...

[sub]

No, you cant do it from the database alone. It needs some API calls.

I'd try running without any plugins for a while (no WDM software recorder etc), then see if you can still reproduce the problem.

[pBS]

hmmm,could it be because i'm up into the 2+million mark in oid's?
will have to really clean it out to lower those..
[resetup cap cards, start with emptydb, and import the rec.dump]

will post if it fixes it...tho i think you might wanna look into updating the wrapper soon anyways...[lots of fixes in ver after yours]

hmm, i think it'll work if i just clear out programme, and recording_schedule tables and re-import..correct?
do reoccuring_extras get saved into the dump?

[sub]

hmmm,could it be because i'm up into the 2+million mark in oid's?

I wouldnt think so. Its not that big of a number. SQLite should be able to cope with this ok.

tho i think you might wanna look into updating the wrapper soon anyways...[lots of fixes in ver after yours]

I will look into it, but as I mentioned earlier - its not straight forward, and will probably break all existing plugins. This will of course mean the permanent death of some plugins that are no longer maintained, since those authors may not return to fix them, so this cant be taken lightly. Last time I changed the version of the SQLite wrapper I seriously pissed some people off.

I've also seen no definitive proof of any bugs being caused in the application due to bugs in the database wrapper. Your database locked problem could easily be a application logic problem, for example a plugin executing a query against the database then forgetting close the reader.

[pBS]

not running any plugins..plugin dir empty...
checked for software recorder stuff and none of it is there. [dlls etc.]
don't think i've ever even run wdm plugin on here...[sig for diff machine]
i've tried to eliminate anything special 'cept for a few custom ffmpeg profiles,which shouldn't
bother anything else.. only the very minimum needed to watch shows..

should have a fresh build next couple days so i'll let you know what happens there..
first i'll try rebuilding the database..

so do reoccuring_extras get saved into the dump? assuming piority order would be preserved

it's got me stumped so far, everythings working great except for this..and i get lots of use out of it and the nmt.. hoping to squash this bug so i can use comm. skin again..

[sub]

so do reoccuring_extras get saved into the dump? assuming piority order would be preserved

Only a limited subset of data is saved, and priority is not one of those data items.