looping: conversion/commercial detection queue

[sub]

That field shown is the title, not the filename. When it generates the filename, it strips the invalid characters including ":".

[mvallevand]

Sorry, I thought maybe the way WizRename worked in the batch file to shorten the name to the episode name, would be a problem.

Martin

[sub]

You could be right. I'm not sure what WizRename does exactly.

[JavaWiz]

I'm currenty out of town for a couple weeks, and do not have access to my development machine. I am 99% sure that the calculated filename is stripped of invalid characters prior to the rename. When I get back, I will try to recreate this problem incase there is a hole in my logic somewhere.

One thing you might try is to quote the %1 replaceable parameter as follows:

Code:

WizRenameRecording.exe "%1" ({episode}{or}{month}{day}@{hour})

[dejunai]

Hello All,

I am appreciative of all the new input...

@JavaWiz: I realize you are out of town, I am not expecting any kinda quick response, I just want you to know that quoting a BATCH argument that was a path has the effect of removing quotes from the argument, and %1 in the case I provided includes the quotes via the basic OS. While I know this from experience, I did actually try your suggestion (based on the suggestion pBS) previously. The result was that WizRenameRecording acted as expect and attempted rename LAW and the batch did try to process ineffectually the remainder of the line after the "& order". Your program is not at fault as far as I can tell; the issue which seems to be unique to my setup; it simply refuses to run PostProcess.bat, once the problem starts. If your program is at fault, it means that something goes wrong on the previous invocation to the problem. And I have yet to find any proof of that, tho I now have a Perl script keeping copies of all logs. If for some unknown and unforeseeable reason I find a pattern, which includes WizRenameRecording, I will let you know.

The problem has not resurfaced today, and several "Law & Order"'s have been recorded; as I suspected the problem is not the "&" so far. Like I have said previously the problem is a doozie. The Perl script, I wrote, is going to collect all the logs before they expire. I am determined to find the problem, and will be happy to explain how I caused it, LOL. Assuming I can eventually determine it.

I will continue to post ZIPs of the logs, if and when the problem occurs.

-Dejunai

[pBS]

you should use "%~1" in case they come with quotes already, this stips any quotes and adds them back, so it always has them whether cmoing in with any or not...
otherwise you get 2 sets ""%1"" which means nothin is quoted...
[~strips begin/end double quotes]

[windows only passes quotes when absolutely necessary,so sometimes yes, sometimes no]

[dejunai]

LOL,

It only happens on oid:3...
It only happens to Law & Order...

I think oid:3 is significant to the problem.
I have set it up to never record L&O on the 3rd recording device...
And so far, no problems at all.

My Devices are as follows,

Device 1 -- WinTV 150 Coaxil (Cable Ready + Internal Tuner) -- oid:1
Device 2 -- WinTV USB Coaxil (Cable Ready + Internal Tuner) -- oid:2
( Same Physical Device )
Device 2 -- WinTV USB S-Video (CableBox + USB-UIRT) -- oid:3

The CableBox can decode channels over 99, And the CableReady has all the channels 99 and below. I disabled all the channels 99 and below on the oid:3 so the CableBox will only be used when necessary. This seems to have fixed the issue.

LOL...
-Dejunai

[erik]

In command processing , especially using the "set" and "if" command, the characters "&" and ":" when used in file names do cause a lot of problems.
Carefully check if you processing is able to cope with these characters