XRecord

[jorm]

It is called ConfirmBox set value equal to true. It should be in the skin as false.

<VideoLines value="7"/>
<GroupLines value="12"/>

<ConfirmBox value="false"/>

<VBRBitMode value="true"/>
<BitRate name="Low" value="3500"/>

[firefox_i]

Quote[/b] (jorm @ Dec. 17 2004,16:08)]That is my last item on my todo list.  I am glad you like the plugin.  I will try to add manual recording in the next few days.

Hey jorm,
did you forget the onscreen keyboard      

Regards
Sven

[jorm]

The onscreen keyboard I am viewing as part of the manual recording. The next release will have the basic manual recording in place. Then I will do a release a few days later with the onscreen keyboard for the recording name.

[Remco]

Quote[/b] (jorm @ Dec. 17 2004,14:39)]v.08 available on wiki.

Let me know if it does not work.  I did it at work and only have 1 drive here.

It works! Thanks.

[jorm]

If you want to test out the manual recording and onscreen keyboad v9 is available on wiki.

I have done some very very basic tests since I do not use the manual recording functionality. Let me know if you see anything funny.

[jrockintuitive]

Jorm,

I noticed a bug... kinda a bug.

If I use padding and attempt to record a program in the next timeslot, xrecord asks me to cancel the first program.

Here is the example: I want to record program "A" starting at 8AM and finishing at 9AM. If I pad the program by one minute on both ends then the program starts recording and 7:59AM and ends recording at 9:01AM.
If I attempt record program "B" that starts at 9AM and ends at 10AM, xrecords asks me to cancel program "A".
In the "Recording" feature that is native to GBPVR, if I attempt to do the above, program "A" will start recording at 7:59AM and end recording at 9AM. While recording "B" will start at 9AM and end recoding at 10:01 AM. This change of recording time occurs, with no extra human intervention.

Can we get this feature in xrecord.

JRock

[jorm]

JRock,

I will gladly fix the bug thank you for reporting it.  I have the code at home so I cant fix it today.  But I would like to get some more information.

This occurs in the manual recording panel?
I just wanted to confirm where this is occuring. I will take a look at the code tonight. I do not remember if I check for conflicts in the manual recording, or was relying on the conflict panel for that resolution.

Jorm

[jrockintuitive]

I'm leaving work in a about an hour. I'll look at the exact steps I did when I get home and report back to you.

Now that I think about it, I think I used your FindFast plug-in.
I chose a program and recieved the cancel dialog as described above.

Sorry for the confussion... and I'll confirm this when I get home.

Thanks always for your quick response

JRock

[jorm]

It makes a lot more sense that it is fast find.

I will try to build a version tonight. Do not download the plugin from wiki. I accidently uploaded a plugin that was not the latest version.

[jorm]

i did find what appeared to be the problem. I did not get a chance to test it.

http://www.bladerhq.com/pmwiki/pmwiki.ph...n/FindFast

If you get a chance test adjacent recordings and just make sure the conflict box does not appear. This occured because the logic I was using to test for the conflict was like,

if ( starttime.ticks >= recording.startTime() &&
starttime.ticks <= recording.endTime() )

The last <= was probably breaking it. Since it would cause the conflict for adjacent recordings changing it to < should fix it.

Sorry it took so long, I had to put my little boy to sleep before getting the 2 minutes needed to fix it.