AVS › AVS Forum › Video Components › Home Theater Computers › HTPC - Mac Chat › HDPVR Support on the Mac (HDPVRCapture)
New Posts  All Forums:Forum Nav:

HDPVR Support on the Mac (HDPVRCapture) - Page 11

post #301 of 1190
Hello stoth - I came across this thread yesterday...and am sure glad I stumbled upon it.

First of all - simply outstanding work, stoth! Thank you very much for your efforts!

I downloaded the demo version of HDPVRCapture (1.3.1) and gave it a try on my MacBook. I have made many recordings successfully at various bitrates. The one snag I have run into is that I just cannot get the IR blaster to change channels on my Comcast box. I am able to change channels from the Windows IR app that ships with the HD-PVR (i.e. BlastCfg). A resulting sample output when I run the HDPVRCapture command is shown below. Any help on why I cannot get the IR blaster to change channels would be much appreciated. Thanks!

abhansal-mac01:bin abhansal$ ./HDPVRCapture -t 00:00:10 -A SPDIF -V COMPONENT -a AC3 -b 5500000 -p 6000000 -f -o /Volumes/Untitled\\ 1/test14.ts -Z "North America,Cable Box,Comcast,85,759,3,0,100"

HDPVRCapture v1.3.1 (Dec 28 2008 @ 20:04:06)
Downloads are available from [removed]
Copyright 2008, Steven Toth.
Demo: restricted to 120 seconds capture

Output filename: /Volumes/Untitled 1/test14.ts
Duration: 00:00:10 (10 seconds)
Monitor via VLC: No (default)
Bitrate : 5500000 bps
Peak Bitrate: 6000000 bps
Device: 0 (default)
Audio Boost: Disabled (default)
Audio Encode: AC3
Audio Input Mux: SPDIF
Video Input Mux: COMPONENT
Bitrate Mode: AVG (default)
GOP Mode: SIMPLE (default)
Lights: OFF (default)
Ir Blaster:
Region: North America
Device: Cable Box
Vendor: Comcast
Codeset: 85
Channel#: 759
Min digits to send: 3
Needs Enter: No (default)
Wait State: 0 (Abort Record (default))
Searching for HDPVR devices, vendor ID=0x2040 product ID=0x4900,0x4901

Found HDPVR, serial number = 00A20856
Captured: 2834432 bytes, success.
post #302 of 1190
Just got my HDPVR and HDPVRCapture is very impressive. I have the box hooked up to a core duo mac mini. The captures look great.

I'm messing around with starting the program from an iCal script, but for some reason the HDPVRCapture only captures for the default 120 seconds even if I put in a longer time parameter. The script is taking 120 secs as the input time; the event reports count down from 120 seconds. (Longer captures are fine if I execute from terminal). Is there some reason why the script would fail to read the license key?

thanks!

ps. here is the script:

tell application "iCal"
with timeout of 7200 seconds
tell (last event of calendar "HDCapture" whose start date is less than (current date))
with timeout of 7200 seconds
do shell script "/Users/afung/bin/HDPVRCapture -o /Volumes/Apollo/hdcapture/" & (summary as string) & ".ts -t 00:09:00 -A SPDIF -a AC3 -b 8000000 -v 1 -f"
end timeout
end tell
end timeout
end tell
post #303 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

Hello stoth - I came across this thread yesterday...and am sure glad I stumbled upon it.

First of all - simply outstanding work, stoth! Thank you very much for your efforts!

Kind words, thanks.

Quote:
Originally Posted by spaghettiq1 View Post

Ir Blaster:
Region: North America
Device: Cable Box
Vendor: Comcast
Codeset: 85
Channel#: 759
Min digits to send: 3
Needs Enter: No (default)
Wait State: 0 (Abort Record (default))

I assume the blaster light actually flashes when using HDPVRCapture, correct?

Are these the exact same values that you've used in blastcfg? If not, can you show what settings you're normally using with blastcfg under windows?

- Steve
post #304 of 1190
Thread Starter 
arfung:

It doesn't know which direct the license key is installed in... Try this:

do shell script "cd /Users/afung/bin ; ./HDPVRCapture -o /Volumes/Apollo/hdcapture/" & (summary as string) & ".ts -t 00:09:00 -A SPDIF -a AC3 -b 8000000 -v 1 -f"

Better?

- Steve
post #305 of 1190
stoth - yes, I am using the exact same values as in BlastCfg. And, no, the blaster light does not flash when using HDPVRCapture; it does flash when using BlastCfg. Any suggestions on what I can do? Thanks!
post #306 of 1190
Thread Starter 
./HDPVRCapture -t 00:00:10 -A SPDIF -V COMPONENT -a AC3 -b 5500000 -p 6000000 -f -o 14.ts -Z "North America,Cable Box,Comcast,85,759,3,0,100"

This flashes for me. Just for test can you change your filename to 14.ts, does this help?

Also, check that the cable is firmly attached to the back of the device.

- Steve
post #307 of 1190
stoth - just tried your command line exactly as is. Still no luck. Also noticed that i do not get the following lines in the output which others seem to be getting:
Loading ir.xml
Booting IR Blaster
Sending channel change information

Also, I don't believe it is a cable problem, since it continues to work from a Windows XP machine using BlastCfg...just verified it.
post #308 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

stoth - just tried your command line exactly as is. Still no luck. Also noticed that i do not get the following lines in the output which others seem to be getting:
Loading ir.xml
Booting IR Blaster
Sending channel change information

Also, I don't believe it is a cable problem, since it continues to work from a Windows XP machine using BlastCfg...just verified it.

Hmm ... doh! I've just checked the source. My fault, not yours. I've just realized that the demo app doesn't let you use the blaster, that's a feature unlocked after purchase. I'll add those details to the FAQ so I don't confuse future demo testers.

- Steve
post #309 of 1190
Stoth - got it, thanks for the clarification re the demo version limitations. At this stage, I will order the full version under the assumption that the IR blaster will work in the full version. Keep up the great work!
post #310 of 1190
Hi Steve,

Thanks a ton for the immediate response. Your fix:

Quote:


do shell script "cd /Users/afung/bin ; ./HDPVRCapture -o /Volumes/Apollo/hdcapture/" & (summary as string) & ".ts -t 00:09:00 -A SPDIF -a AC3 -b 8000000 -v 1 -f"

Did the trick.

For those interested in scheduling via iCal launched script, I've improved the script from edalzell. This one takes the filename from the event title, but then takes the record time from the duration of the event as well. Also, I put in a long manual timeout because iCal was aborting my script.

Here it is (presumes that your recording events are in a calendar called "HDCapture"):

Code:
-- application to be called from an iCal event
-- this script tells the HDPVRCapture program to start recording
-- file name is given by the title of the iCal event
-- duration of recording is given by the duration of the iCal event
-- created on 12/30/2008

tell application "iCal"
        with timeout of 10800 seconds
                set theDate to current date
                set theEvents to {}
                set theEvents to events of calendar "HDCapture" whose (start date is less than or equal to theDate and end date is greater than or equal to theDate)
                set theEvent to ""
                set duration to 0
                set filename to ""
                
                -- this is an error condition that should never happen since script is called from iCal alarm
                if ((count of theEvents) is equal to 0) then
                        return "Nothing Scheduled"
                end if
                
                if (count of theEvents) is equal to 1 then
                        set theEvent to item 1 of theEvents
                else
                        set theEvent to last item of theEvents
                end if
                
                -- get the filename and event recording duration (in seconds) from the iCal event
                set filename to summary of theEvent
                set duration to (end date of theEvent) - (start date of theEvent)
                
                do shell script "cd /Users/afung/bin ; ./HDPVRCapture -a AC3 -A SPDIF -V COMPONENT -b 8000000 -f -o /Volumes/Apollo/hdcapture/" & (filename as string) & ".ts -T " & (duration as string)
        end timeout
end tell
post #311 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

Stoth - got it, thanks for the clarification re the demo version limitations. At this stage, I will order the full version under the assumption that the IR blaster will work in the full version. Keep up the great work!

Thanks. If you have any blaster issues then we'll be able to solve them very quickly.

Welcome aboard!

- Steve
post #312 of 1190
Thread Starter 
arfung: Nice script. I'm glad you have a working solution.
post #313 of 1190
Stoth - the blaster now works with the registered version. However, the bitrate falls down to 0 in a few seconds after the channel is changed and recording begins. Any ideas what could be going on? thanks!
post #314 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

Stoth - the blaster now works with the registered version. However, the bitrate falls down to 0 in a few seconds after the channel is changed and recording begins. Any ideas what could be going on? thanks!

Every time 100% reliably, or only after it blasts? Does it occur if you don't blast?

Another user reported a similar problem but the issue was believed to be related to a 15ft long USB cable.

Post your exact command line args and I'll try and repro.

- Steve
post #315 of 1190
stoth - When the IR blaster is used, it is an intermittent problem. When the IR blaster is not used, it never seems to happen. The exact command line args are as follows:

./HDPVRCapture -t 00:03:00 -A SPDIF -V COMPONENT -a AC3 -b 5500000 -p 6000000 -f -o /Volumes/Untitled1/ChasingCars.ts -Z "North America,Cable Box,Comcast,85,754,3,0,100"
post #316 of 1190
Thread Starter 
What happens of your remove -p 6000000?
post #317 of 1190
stoth - removing -p 6000000 had no effect. What I am finding is that if the blaster actually changes the channel, then the bitrate goes down close to zero as part of the recording. If the blaster is used, but the box is already on the desired channel such that the channel does not actually change, then the problem does not occur...and the recording is successfully carried out.
post #318 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

stoth - removing -p 6000000 had no effect. What I am finding is that if the blaster actually changes the channel, then the bitrate goes down close to zero as part of the recording. If the blaster is used, but the box is already on the desired channel such that the channel does not actually change, then the problem does not occur...and the recording is successfully carried out.

I've fixed (by choice) my STB output resolution to 720p regardless, so the post processing tasks work correctly. Is your STB fixed or does it vary between channels? Can you fix it and does that make a difference?

I'm using a SA4250HD.

I ran your commands here 5 times back to back with no hangs or errors.

- Steve
post #319 of 1190
My STB is fixed at 720p for all channels...so don't believe this is the problem.

My workaround for now is to set up a very short recording which executes the channel change, resulting in o recording. And then proceed with the real recording without the channel change. This works every single time.

I am wondering whether I have a defective HD-PVR unit?
post #320 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

My STB is fixed at 720p for all channels...so don't believe this is the problem.

My workaround for now is to set up a very short recording which executes the channel change, resulting in o recording. And then proceed with the real recording without the channel change. This works every single time.

I am wondering whether I have a defective HD-PVR unit?

More than likely the encoder is starting too early, while the channel change still occurs. This is known to confuse the encoder.

I've added a 'wait X milliseconds' to the IR blaster args, you will be able to specify a time to wait after blasting before the encoder should start. I suspect this will solve your issue.

I'm about to release v1.3.2 this via the blog, check the command line usage, see the extra arg to the -Z option.

http://steventoth.net

- Steve
post #321 of 1190
Steve - what value do you suggest I try for the time to wait after blasting before the encoder starts in v1.3.2?
post #322 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

Steve - what value do you suggest I try for the time to wait after blasting before the encoder starts in v1.3.2?

See what works for you.

I'd suggest 2000 (ms) but you might get away with 500, or worst case you may need 5000.

- Steve
post #323 of 1190
900ms works...I have tested it a few times...v1.3.2 seems to have done the trick. Thanks for all your help in getting this issue sorted out! Very much appreciated.
post #324 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

900ms works...I have tested it a few times...v1.3.2 seems to have done the trick. Thanks for all your help in getting this issue sorted out! Very much appreciated.

You're welcome, I'm happy this helped.
post #325 of 1190
Hi Steve,

I'm experiencing an issue in which the HDPVR stops recording (the record lights go off) after some period of time (between say 5 and 70 minutes). I haven't ever been able to get a full 2 hour recording.

The HDPVRCapture program keeps recording the stream until the set time runs out, but the application isn't receiving any data.

Anyone else run into this? Any thoughts?
post #326 of 1190
Thread Starter 
arfung: Myself and other people have made some very long recordings in the past (3+ hours) without any issues, although I guess given the varied environments anything can happen. I've seen intermittent reports of this in the past, from various people. That detail is in this thread history.

I've witnessed that issue under very high CPU and disk loading but never under other conditions.

My suspicion is that the input video signal somehow changes and that confuses the hardware encoder.

Two question for you:

1. Is your STB output resolution fixed to 720p? (If not, try that).
2. Can you try entering the STB menus (so no video is playing - just static graphics) and do a 2 hour recording, does that work reliably?

- Steve
post #327 of 1190
Hello Steve,

I just tried using HDPVRCapture to capture analog video/audio from a Hi8 camcorder connected directly to the HD-PVR via the front composite video and RCA audio inputs. The command I am using to capture is as follows:

./HDPVRCapture -t 00:02:30 -V COMPOSITE -A RCA -a AAC test.ts

When I play back the file using VLC on my MacBook, I am able to playback the video fine, but I get no audio. My VLC player works fine with other AAC audio files.

Just to be sure, I then connected the Hi8 camcorder directly to my TV using the same cables I was using to connect to the HD-PVR...and the audio worked fine.

Any ideas why I would not be capturing audio with the HD-PVR?

Thanks!
post #328 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

Any ideas why I would not be capturing audio with the HD-PVR?
Thanks!

Smells like a bug, I'll fix this in the next day or so.

If you connect the HI8 audio via the rear RCA jacks I suspect it will work, does it?

- Steve
post #329 of 1190
Steve - yes, the rear RCA jacks work. Thanks!
post #330 of 1190
Thread Starter 
Quote:
Originally Posted by spaghettiq1 View Post

Steve - yes, the rear RCA jacks work. Thanks!

I went hunting and fixed the bug. It's fixed in v1.3.3, out in a couple of days.

The -A option will now take RCA (defaulting to back panel) RCA_FRONT, RCA_REAR or SPDIF.

Thanks for reporting this, regards.

- Steve
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: HTPC - Mac Chat
AVS › AVS Forum › Video Components › Home Theater Computers › HTPC - Mac Chat › HDPVR Support on the Mac (HDPVRCapture)