Topic: Hauppauge PVR HD 60 - help needed (Read 20960 times)

MikeG · « **on:** February 26, 2016, 03:33:42 pm »

Hi

I am new to JRiver. I started on windows Media center and, after its demise, went the long way around via kodi, nextpvr etc before discovering the total awesomeness of JRiver!

I can't believe that the others are still trying, JRiver is so far ahead!!!

However.... :-)

I saw that, after some encouragement, some people had got the hauppauge usb PVR HD 2 to work as a capture device.
I was going to buy one, but instead I bought their newly released usb PVR HD 60. This had a better encoder but I thought would connect roughly the same way that the PVR 2 did.

Unfortunately I was wrong! JRiver can see the device and it sets up just fine. However when you play the TV channel you get the overlay displayed saying it couldn't construct the graph and asking if you have another app open.

I can build the capture graph manually in graphedit with the normal cross bar, capture and hardware decoder stuff. JRiver can decode and render a saved file from the graph. It's just that JRiver doesn't seem to be able to construct the graph by itself for some reason.

Ironically nextPVR works fine with the device.

Is it possible to get some help? More than happy to carry out tests and report settings etc - just not sure where to start.

Thanks in advance

Mike

Yaobing · « **Reply #1 on:** February 26, 2016, 06:10:38 pm »

We have not had chance to deal with this device yet. So you are the first one. With your help we can make it work.

Please do the following two things for me:

Turn on logging and email me a log.
Go to TV Options, Advanced, Copy television related filter info to clipboard...

You can paste the filter info in the email body when you email the log.

I am yaobing at jriver dot com

MikeG · « **Reply #2 on:** February 27, 2016, 06:02:11 am »

Hi Yaobing

Thanks so much for the kind offer of help.

I have emailed the material you requested to your address. Please let me know if you don't receive it or if there is any problem.

If you need anything else then please let me know.

Thanks again for the support,

Mike

Yaobing · « **Reply #3 on:** February 27, 2016, 08:19:59 am »

Email received. I will work on it early next week.

MikeG · « **Reply #4 on:** February 27, 2016, 09:07:04 am »

Awesome - thanks, have a good weekend.

Mike

Yaobing · « **Reply #5 on:** February 29, 2016, 05:14:45 pm »

Please try using this DLL

Install MC21.0.50 first, if you have not already done it. Then download the dll and copy it into MC21 installation folder, replacing the existing one.

MikeG · « **Reply #6 on:** February 29, 2016, 07:03:15 pm »

Hi,

Thanks for the speed reply and the help.

The new dll is definitely progress. The graph is now created without error. I can see it by attaching graph edit. The graph is also started and runs.

However the renderers are not receiving frames and so there is no video or sound.

I have taken the log and the TV filter info and will email it shortly.

Just in case it is any help at all, I will also attach a picture of the graph MC greatest vs the Hauppauge app.

Obviously the choices of decoders will be different and Hauppauge puts the stream through a time shifter so you can't see the capture filter itself in this shot. However one thing I did notice was that the media format coming out of the demux was different between the two graphs.

Probably not relevant but I thought I would mention it just in case.

Anyway - definitely moving forward, thanks for the awesome help and if I can send you any more info then please let me know,

Mike

Yaobing · « **Reply #7 on:** February 29, 2016, 07:28:17 pm »

Please set MC to record in TS format, and try recording a short program. Will you be able to record? Does the recording play inside MC?

MikeG · « **Reply #8 on:** February 29, 2016, 07:40:41 pm »

Hi, no problem,

Switched to ts, viewed the "capture" channel- black screen.

Selected record. MC said waiting for signal lock, then no signal. After 3 attempts it gave up with an error dialog.

Hope this helps

Mike

Yaobing · « **Reply #9 on:** March 02, 2016, 11:35:24 am »

Please try this DLL.

MikeG · « **Reply #10 on:** March 03, 2016, 07:05:46 am »

Hi Yaobing,

More progress :-)

When I tried the new dll initially, media center locked and a status light on the hd pvr indicated that the encoder could not get the pc to accept the data stream. I had to kill the media center task.

However, I realised from the graphs I sent you that MC was not initialising in time shift mode because the pvr was analog.

I altered the setting to 'always time shift analog' and when viewing the TV channel in MC it started correctly and showed a picture of the first frame of the incoming signal. Looking at the graph, the capture side is running and pumping data into the TS buffer. The render graph also looked ok.

The TV OSD always indicated I was at the end of the time shift buffer. I tried to jump back to earlier. Although it instantaneously shows me a previous frame, MC immediately jumps back to the end of the buffer. The time display would be continually updating: for example, position 1 minute of 1 minute then 1 minute 1 second of one minute 1 second etc. As the length extended the position always matched it and stayed at the end.

I tried recording to TS. This worked perfectly (although the time shift had the above problem). The TS recording file plays in MC and externally.

However if I changed the record format to JTV then, although an appropriate length set of files were produced, MC could not play the recording correctly. When I tired it again displayed the last frame in the file and, although I could rewind, it immediately jumped back to the end and eventually exited.

Hope the above makes some sense, it's a bit hard to explain. If you want the TS or the JTV recording the let me know, if you want any graph caps or logs then let me know what you want me to capture.

Thanks again for the help, feels like we are very close now.

All the best

Mike

Yaobing · « **Reply #11 on:** March 03, 2016, 09:11:00 am »

Yes please forward another log. Also please forward a short TS recording file. For the latter you may need to use a file sharing site (unless it is really short).

MikeG · « **Reply #12 on:** March 03, 2016, 01:32:12 pm »

Hi

You should receive two emails sharing the log+filter info and the 3 minute TS file. Let me know if you can't access them.

The TS was taken with time shift enabled for analog and so two graphs. The TS plays fine in MC but when demuxed by MC during recording and written in parallel as the JTV it had the problems I described.

Hopefully if you convert to JTV as MC would have when recording you will see the same effect,

If you need anything to help then please let me know

I am very appreciative of the time you are spending on these investigations.

Mike

RoderickGI · « **Reply #13 on:** March 03, 2016, 06:05:27 pm »

Just FYI, when you are recording in TS format, and also have Time Shifting turned on, both files formats are written in parallel. There is no conversion between the two, or demuxing from TS to JTV format. The stream is written twice, once to each format. Time Shifting is always saved in JTV format, regardless of the recording format selected.

I am not positive (because I'm just a user like you), but I think that if you are recording in TS format, and use Time Shifting to move back and forth in the program, then MC would be playing the JTV files, not the TS file.

If you watch a channel live without recording, and then try to Time Shift within the program, you should be able to find temporary Time Shift JTV file in your TV recording folder, should you go looking. Normally those are deleted once the Time Shift session is ended.

So it sounds like both your Time Shifting issue, and problems with recording in JTV format, are related to the JTV format used. Your observations make sense to me, based on the above information: JTV recording isn't working properly.

Yaobing · « **Reply #14 on:** March 03, 2016, 06:25:40 pm »

Yes. Time-shifting is running whenever there is a recording going on, even if you record in TS. And our time-shifting is not done through the TS file.

Please try again - "Take 3".

Send another log regardless of the result. Do not cut off the beginning of the log.

MikeG · « **Reply #15 on:** March 04, 2016, 01:17:36 am »

Hi both

RoderickGi -

Many thanks for the input and appologies for any confusion my imprecise description has caused. I understand about the dual record process with a stream to TS and JTV files. In my case however the card's hardware decoder is set to deliver a TS natively into the graph. MC puts this output through a DS infinite-T filter. One side is then written directly to the TS file. MC passes the other side of the split through a demux filter to get an elemental vid and audio stream which drive the JTV file encoder/writer. The file from the Raw TS branch is fine but the other side, demuxed and written as JTV format, is not.

I was concerned that I hadn't been able to explain the issue I was seeing with the time shift very clearly. However, because the TS file I sent to Yaobing is exactly what the card hardware outputs, I hoped this could be used to allow Yaobing to see the same thing without having the hardware itself. If a test graph was constructed which re-read the TS file and artificially puts it through the same demux and encode to JTV that MC is doing then Jaobing might be able to see what I was seeing.

When I try to watch live (with TIme shift option disabled, not just without rewinding) , that's when MC locks up completely. However in this case MC builds a single DS graph. It captures, demuxes, decodes (Lav) and renders all in one graph rather than the two used to time shift via a file buffer. In this case, with no time shift and no record, I can't see any output file being written away by the graph.

Hope this is a more complete description. Thanks again for the help both. I am just off to try the new DLL. Will report back soon.

Mike

MikeG · « **Reply #16 on:** March 04, 2016, 04:41:01 am »

Hi

I have finished the testing - some really great results but a couple of remaining problems.

I described it all in an email with the logs - I have copied the email below for information...

=====================

Hi Yaobing

Some good news - the latest DLL improves things a lot.

I have done the following tests and attached corresponding logs:

Test One - On the server Machine attached to the Capture card - Start Analog in Time shift mode ENABLED

Record in TS: Now Works - TS captures and plays back PLUS the JTV Timeshift now works as expected with full play back
Record in JTV: Now Works - JTV Timeshift now works as expected with full play back, JTV file recorded and can play back
Log for the second test is in file : "Time Shift Enabled - Watch on Server.txt"

Test Two - On the server Machine attached to the Capture card - Start Analog in Time shift mode DISABLED

Still fails - MC hangs and the error light blinks on the capture device
I killed the MC process, restarted it and saved the log to : No Time Shift Local - Watch on Server.txt"

Test Three - Client Server

I now set up a second PC and shared the library from the machine with the capture card acting as the server - Hope I did this correctly.
The second machine (client) correctly saw the server's configured TV line up.
This had the capture card channel and also other channels from a another DVB-S Card.

If I double clicked the capture card channel on the client machine it did cause the server to start capturing. The capture card LED light up and a Graph was created showing it buffering to a file.
HOWEVER - Despite the correct activity on the server, the client eventually said there was no television tuner available

NOTE - When I did the same for a Channel from the DVB-S card everything worked. I saw the TV live feed from the Satellite TV Card on the server sent correctly to the client where it rendered correctly

When I did the above test I captured logs for the Capture card channel not working from the client followed by the satellite card channel working correctly (both in the same log)
I have attached the log from the server machine "Log From Server - Watch Channel Initiated From Client.txt"
I have also attached the log from the client - "Log From Client.txt"

Hope that this gives you what you need. As always - thanks for the help

Mike

MikeG · « **Reply #17 on:** March 04, 2016, 05:07:51 am »

Just to confirm - I put the latest new DLL on both the client and server machines for the last test

Yaobing · « **Reply #18 on:** March 04, 2016, 11:27:01 am »

I have not looked into client playback problem yet. For local playback without time-shifting, there may be an issue with audio format specification.

I have to experiment with different formats. Here goes - take 4.

A word about getting log files. The log file "No Time Shift Local - Watch on Server.txt" does not contain any useful info, likely because you had to restart MC. Whenever you restart MC, the log file from before the restart is moved to "Previous Log.txt". The correct way of getting that file is to click "Report problem..." button. Clicking that button will pack "Log.txt", "Previous Log.txt" and "System info.txt" into a zip file and put on your desktop. Alternatively, you can find "previous log.txt" in

C:\Users\[user]\AppData\Roaming\J River\Media Center 21\

MikeG · « **Reply #19 on:** March 04, 2016, 12:36:38 pm »

Hi Yaobing,

Sorry about the log. The instructions are all over the dialog and the forum but I got carried away , forgot to read them, and messed it up :-) it must be frustrating as you have gone to the trouble of making the correct process really easy.

I tried v4. No visible change I am afraid. However I recaptured the log using the correct process so hopefully this will provide more info this time. Let me know if I have still made a mistake in this.

I am fine with helping to identify and test this and I am guessing you want to do this for other users. Just in case it's relevant , for me personally, I will always use time shifting mode so it doesn't inconvenience me. I didn't want to waste your time if I was the only reason you wanted to pursue it.

The client server issue is going to hurt me. My worry here is I may have set it up incorrectly (although the satellite card does work). I thought that if it was correctly set up I should not be able to watch TV on the server anymore just via the client. However I seem to be able to do it on both. Also neither client or server has a watch button (which I thought I remembered being there) I watch by double clicking the channel name.

Let me know if I can help further

Mike

Yaobing · « **Reply #20 on:** March 04, 2016, 01:49:00 pm »

Thanks for the help.

The hang occurred in a place that is inexplicable

Please try this DLL that has more logging.

The problem of playing on a client hopefully has been fixed, but it can not be tested with this DLL update alone. So you will have to wait for a new release (build 55 or later).

MikeG · « **Reply #21 on:** March 04, 2016, 01:56:35 pm »

No problem. I am out at the moment but I will try it as soon as I get back. Client server fix in 55 is great news. I'll look forward to it :-)

MikeG · « **Reply #22 on:** March 04, 2016, 03:50:29 pm »

Hi Yaobing,

I just sent you the log file from the extended diagnostics dll test.

If you need to add debugs in more places then just let me know and I will happily test the dll and send the log.

Mike

Yaobing · « **Reply #23 on:** March 04, 2016, 05:24:49 pm »

Thanks. I got the log. More logging did narrow the hang to a precise location, but I am still puzzled at why it happens. Will work on it more next week.

MikeG · « **Reply #24 on:** March 05, 2016, 12:34:50 am »

Great - good luck.

Yaobing · « **Reply #25 on:** March 07, 2016, 04:18:51 pm »

Please test this one for viewing without time-shifting.

MikeG · « **Reply #26 on:** March 08, 2016, 03:08:29 am »

Hi Yaobing

I have tried the next version and emailed you the log. As usual, each new version improves things and moves forward :-)

The good news is that the capture card doesn't show an error and MC doesn't hang. Also we get a picture from the TV source.

The bad news is that there is no Audio.

The Log I sent you is with Time shifting turned off, a single graph is built and you see picture without sound.
The previous log included in the zip will have been with Time Shift On and shows the double graph producing picture and sound. I din't know if the comparison might be helpful so I included it.

If you need anything else then please do let me know.

Mike

Yaobing · « **Reply #27 on:** March 08, 2016, 11:52:42 am »

I hope this one will continue moving in the right direction.

MikeG · « **Reply #28 on:** March 08, 2016, 12:49:38 pm »

Hi,

I am afraid that this one didn't seem to. Please do check that I haven't done anything wrong from the log. This version went back to the previous behaviour of hanging MC and an error on the capture card. No visible difference between this and the one before last with no sound.

When I started MC, it did upgrade to 21..54 though. I also had to resetup the capture device so don't worry that details may not be the same.

As always, let me know if I can help.

By the way. You mentioned that the client server issue was fixed from version .55 so I shouldn't retest in this upgrade?

Thanks

Mike

Yaobing · « **Reply #29 on:** March 08, 2016, 01:23:01 pm »

Build 54 did not contain the client-server change. So you do not need to test that aspect yet.

In my previous change, I made two changes at once. In this new one I reversed one change just to see which earlier change had the good effect. The result is not good because I have to hard-code audio stream ID.

Please resend the latest logs (I think you sent an old package by mistake).

MikeG · « **Reply #30 on:** March 08, 2016, 03:19:45 pm »

apologies , resent the logs. i am amazed at how far hauppauge have deviated from the pvr2. sorry to put you to so much trouble. i am curious why the graph decoding from a saved ts works but the one decoding from the live ts data doesn't. also what on earth they did to stop the original graph build at the beginning that you first fixed. really appreciate the time and the help.

Yaobing · « **Reply #31 on:** March 08, 2016, 03:40:36 pm »

HD PVR/PVR2/Colossus all use the same set of audio and video stream IDs. PVR60 uses a different set. What I was experimenting earlier was to see if we will be able to be independent of this knowledge. Unfortunately, the non-time-shifting graph hangs when we try to map the audio stream ID dynamically. Not sure why it is the case. One guess is that the audio decoder is busy trying to handle the wrong audio type when we try to re-map the stream id. With time-shifting on, we just buffer the data without trying to interpret/handle the data.

For now I will just set the audio stream ID to the correct value by hard-coding it so we will not need to do a dynamic mapping.

Yaobing · « **Reply #32 on:** March 08, 2016, 03:46:35 pm »

Here we go. The new DLL will have hard-coded audio PID at the start of graph-building so we will not need to re-map. The audio format specification is modified and I hope the down-stream decoder filter will accept it.

MikeG · « **Reply #33 on:** March 09, 2016, 08:44:44 am »

Hi Yaobing.

Success !!!

I understand it's a fixed PID which isn't what you wanted but it does capture correctly now whether time shifting or not.

What is strange is the PSI filter can't determine the correct available stream PIDs when connecting to the capture device directly. However (in time shift) write this capture output unchanged directly into a file, read it out again and use the same decode and render graph and this time the PSI info is sufficient to program the demux mappings and play the file.

Another oddity is that when decoding and rendering directly from the device in a single graph the CPU is between 60% and 90% on all cores (tiny 4 core atom). However when time shifting,both graphs are on the same machine, the sum total of the work is the same PLUS a file read and write BUT all Cpu cores sit at about 15% decoding and rendering beautifully.

Anyway, I am really just feeling my way in these things so there is a huge amount I don't understand.

It's been a fantastic amount of time and effort from you and I just wanted to say a big THANK YOU!!!!

I will eagerly await a release that allows me to use the device in client server mode. Will these test dll changes be rolled into that version also?

Thanks again - I've really enjoyed participating, if ever I can be of help to you then please let me know.

Mike

JimH · « **Reply #34 on:** March 09, 2016, 09:04:05 am »

Thank you for your help. You did a great job of reporting what you found.

MikeG · « **Reply #35 on:** March 09, 2016, 09:28:08 am »

You're more than welcome. It's been great working with such clever and receptive people. Now that I have discovered you all and MC, I'll definitely stop by the forums regularly. As I learn more, hopefully I can contribute some ideas and not just bugs :-)

JimH · « **Reply #36 on:** March 09, 2016, 09:34:33 am »

I should also say "Well done" to Yaobing for his patience and detective work. Thanks, Yaobing!

Yaobing · « **Reply #37 on:** March 09, 2016, 12:24:34 pm »

Thanks Mike for your help!

Thanks Jim for your encouragement.

The PSI filter does detect the correct PID. The trouble is if I do not start with a hard-coded correct PID, and try relying on PSI filter's detection, we could not change the PID when in non-time-shifting graph.

MikeG · « **Reply #38 on:** March 09, 2016, 03:24:54 pm »

Hi

Yes that makes a lot of sense. Thanks again for your help Yaobing.

Mike

jgreen · « **Reply #39 on:** March 10, 2016, 03:34:47 pm »

Mike, any interest in doing a detailed review for the rest of us? I was so badly burned by that PVR2 that I've more or less given up on Hauppauge for the future. I'd buy a decklink if I could be certain of getting functinal win 8.1 drivers.

Yaobing · « **Reply #40 on:** March 10, 2016, 04:07:38 pm »

One thing on the PVR2 that is very bad is the mini USB port. It just can not support the weight of the cable itself. It is one of the possible reasons that the device is unstable.

MikeG · « **Reply #41 on:** March 10, 2016, 04:30:01 pm »

If it would be be of interest to people then I am more than happy to jot down some observations. I'd like to hold off until the MC bug fix release which allows me to use the device in client server mode so that I can fully test it. I haven't used the pvr2 so i can't compare. However I can put the hd60 through its paces. I also bought (and sent back) the avermediahight bit rate USB device which was an interesting experience and led me to the hauppauge route.

The decklinks are in a different league but in the main capture uncompressed which didn't fit my use case!

I'd also be interested to hear your concerns around the pvr2. If it is stability then I may have that all to look forward to. So far I have just been getting the hd60 working functionally . I haven't used it over a long period or done a soak test yet

Do you think a mini review would be of interest to people?

All the best

Mike

jmone · « **Reply #42 on:** March 10, 2016, 04:36:04 pm »

I too have a PVR2 sitting in the cupboard doing nothing as the thing is so unstable it would lock up all on its own. The original intent was to record items from the STB. I'd be interested to see any review you do on the HD60, in particular:
- Video : How does it look and does it support 50hz (for us PAL folk)
- Audio : Can you capture Multi Channel Audio or just Stereo

Any short clips you could make and link to would be great

Thanks for all the work!

Nathan

MikeG · « **Reply #43 on:** March 10, 2016, 05:01:15 pm »

OK, no problem at all. I will get on it as soon as the MC release with the bug fix comes out.

INTERACT FORUM

Author Topic: Hauppauge PVR HD 60 - help needed (Read 20960 times)