[PC] SamyGO PVRDecoder for E/F/H series - Version 1.8.2.53

[digiwatch]

The Decoder apparently works. It converted the files from my TV. However, I can not find the relevant .ts file in my database on my PC. I did choose for the working folder and .ts save folder my D:\ drive. Any hint what I am doing wrong ?

[MikeyBoy]

The Decoder apparently works. It converted the files from my TV. However, I can not find the relevant .ts file in my database on my PC. I did choose for the working folder and .ts save folder my D:\ drive. Any hint what I am doing wrong ?

I had this with a new recording too. Then i used a different working folder and output folder, tried again, and the file was there.

Then, when i wanted to delete the recording from the TV via PVRDecoder, it wasn't deleted, meaning it was still in the list after a refresh. When i checked in the TV PVR menu, the recording was also there, but with a crossed out sign over the generic thumbnail pic. But i could delete it there.

[Lordbyte]

I had this with a new recording too. Then i used a different working folder and output folder, tried again, and the file was there.

I believe thats a simple matter of where YOUR permissions allow you to write .. Windows is funny that way ... "Normally" you cannot write to "C:\", but you CAN write to "C:\TEMP".
Get control of your permissions when you experience non-working directories !

... when i wanted to delete the recording from the TV via PVRDecoder, it wasn't deleted, meaning it was still in the list after a refresh. When i checked in the TV PVR menu, the recording was also there, but with a crossed out sign over the generic thumbnail pic. But i could delete it there.

Actually, the RECORDING *has* been deleted ... What you see (cross out sign) is a reminance in the TV?s database.
It will be removed when TV is powercycled, or rebooted.
You will actually see the PVRDecoder offer to reboot the TV after a delete-operation to flush the database, if you enable it in settings.
The reason for offering reboot is that we (the SamyGO community) have found no way to access the TV database directly (yet).

[MikeyBoy]

Get control of your permissions when you experience non-working directories !

The folder i first tried also had full permissions set. I always set full permissions for the user for partitions other than C:\.

About the deletion, that makes sense.

[Lordbyte]

Get control of your permissions when you experience non-working directories !

The folder i first tried also had full permissions set. I always set full permissions for the user for partitions other than C:\.

Well, I am pretty convinced ... please open dos-box, and run ICACLS (windows/system32)

Study it, and then apply the correct attributes to your non-working directory ...

[MikeyBoy]

My G:\ partition has full permissions set without a doubt. And that's what i first used where the file wasn't there afterwards. Let's wait what digiwatch replies, i bet he also had write permissions...

[Lordbyte]

My G:\ partition has full permissions set without a doubt. And that's what i first used where the file wasn't there afterwards. Let's wait what digiwatch replies, i bet he also had write permissions...

OK, accepting your premiss of thought ... What would motivate the PVRDecoder to accept ONE folder, and reject the NEXT ?

Funny chars in name ?? .... Naaaa .. if windows accepts it, the PVRDEcoder does too.

File already present (and locked) ?? ... Naaaa .. I employ an algorithm that ensures unique filenames.

Can you come up with a scenario that "fits" ?

PS: I have to mention that the PVRDecoder is only the "data-source"-provider for DRMDecrypt, a tool made by Bugficks.
DRMDecrypt is the "one" that actually creates and writes the contents of the file.

Can you detect "working files" in the work-folder ?

[MikeyBoy]

I can only tell you what happened, not why. First i had working and output folder both set to G:\. It was only for a single recording. After the decoding, i checked a for a file, there was nothing in the root dir, no working files either. Then i set both folders to T:\, and after that second decoding, the file (.ts) was in T:\ as it should be. Both G:\ and T:\ have full permissions allowed for the user. I honestly don't know what happened. I think there was nothing in the log file about "removing unneeded files" this time. But as i said, maybe make the new log entries append at the end, not overwrite older entries, would be better.

[Lordbyte]

I can only tell you what happened, not why. First i had working and output folder both set to G:\. It was only for a single recording. After the decoding, i checked a for a file, there was nothing in the root dir, no working files either. Then i set both folders to T:\, and after that second decoding, the file (.ts) was in T:\ as it should be. Both G:\ and T:\ have full permissions allowed for the user. I honestly don't know what happened. I think there was nothing in the log file about "removing unneeded files" this time. But as i said, maybe make the new log entries append at the end, not overwrite older entries, would be better.

Well, as the PVRDecoder has NO way to know what the difference between your G:\ and your T:\ is, - it HAS to be environment-related.
Anyway .. as you suggest. lets wait for more feedback so we can hatch a theory.

From start to end of a PVRDecoder-session, the log should be appending ...
And persisting log across sessions seems to me of no use .. Is that a request others would want ?

[MikeyBoy]

The log gets overwritten each time you click "Decode selected recordings". I had to decode multiple times because of that network/HDD error, so the valuable first log was overwritten before i thought about saving it for later analysis.

P.S. Tried again decoding to G:\, it works, so the permissions are ok.