GB-PVR rec. service locks my classlib

[bgowland]

The title says it all really. I discovered recently that when I try to copy a new version of the DvbrLib.dll into the plugins\DvbRadio folder, Windows tells me the file is 'in use' by another person/process. I found out I have to stop the GB-PVR recording service to allow the file to be copied.

I'm not sure what I've changed in my code or how this can possibly be happening. The dvbr solution consists of the plugin itself, the dvbr service (Windows Service) and the DVbrLib.dll which is purely for shared classes (collections and datasets etc. which both the plugin and service use).

What's really odd is that simply restarting the gbpvr rec. service still won't allow me to copy the dvbrlib.dll in - as if the rec. service stops/starts and regains its lock. I have to stop the rec. service, copy the dll then restart the rec. service.

What is there in the rec. service that would maintain an open handle on a plugin's class library.

Cheers,
Brian

[sub]

The recording service loads plugins in the 'plugins' directory, looking for 'recording plugins'. It sounds like the garbage collection doesnt kick in to release the plugins it loaded to check for recording plugins, but didnt find any appropriate classes.

[bgowland]

The recording service loads plugins in the 'plugins' directory, looking for 'recording plugins'.

OK, I didn't know that. So it will try all .dll files?

One thing I'm wondering about is that I created a static class in DvbrLib.dll to help pvrx2.exe resolve it as per psycik's suggestion in Post #6 here...

http://forums.nextpvr.com/showthread.php...post322989

Doing this has meant I no longer have to have dvbrlib in the plugins\Common folder. COuld this be the cause? (I've always been a bit 'grey' about static classes etc.)

[psycik]

The recording service loads plugins in the 'plugins' directory, looking for 'recording plugins'. It sounds like the garbage collection doesnt kick in to release the plugins it loaded to check for recording plugins, but didnt find any appropriate classes.

orly??

I've found that it locks my MusicLibraryCommon.dll Always assumed that was by design for some reason. Didn't know it was looking for recording plugins.

What makes a plugin a recording one? What interface should it be using? Hopefully different to IMenuTask

[psycik]

OK, I didn't know that. So it will try all .dll files?

One thing I'm wondering about is that I created a static class in DvbrLib.dll to help pvrx2.exe resolve it as per psycik's suggestion in Post #6 here...

http://forums.nextpvr.com/showthread.php...post322989

Doing this has meant I no longer have to have dvbrlib in the plugins\Common folder. COuld this be the cause? (I've always been a bit 'grey' about static classes etc.)

If you call your static method at constructor time, then yes you should be able to move the extra dll to the local plugin directory rather than common.

[bgowland]

If you call your static method at constructor time, then yes you should be able to move the extra dll to the local plugin directory rather than common.

That's what I was doing and it worked fine (no need to use plugins\common). I've removed that static class from dvbrlib now and the rec. service doesn't seem to be locking it any more but I'm having to use plugins\common again.

[sub]

What makes a plugin a recording one? What interface should it be using? Hopefully different to IMenuTask

Its looking for IRecordingSource. It doesnt know what it'll contain until its loaded the DLL though.