Now I want to not use the IR emitter on Colossus but I want to use the IR control on MCE IR receiver.
I expected turning off the "Use Internal Blaster" illustrated on that page would do the trick but it didn't.
+ Reply to Thread
Results 31 to 45 of 45
Do you have the MCE IR receiver still hook up ? maybe you unplug that and leave out and start over.
Apparently you have use Hauppauge IR32 and BlastCfg so need that check the Use Internal Blaster for it all work and there still no guarantee it will work because MS has so min change with patch over the years I'm sure it even more broken then before.
If can't you get work why not just get a diff DVR software as that software was just a beta any way and is no longer being support when DVBLink kill it right long with there own product at time.
Sorry I can't test it as I longer have any Windows 7 system lay around
Yes, I used Hauppauge IR32 and BlastCfg for IR blaster on Colossus to work. It's been working fine but IR window on Comcast cable box got scratched and IR signal doesn't seem reaching very well these days. So I want to get rid of the IR blaster on Colossus and replace it with the IR emitter on MCE IR receiver via the direct connection cable which usually_quiet used to have been doing so according to his post few years back.
I'm wondering how usually_quiet made Windows not to recognize Colossus as Digital Tuner so that you can configure MCE to learn IR code from Comcast cable box.
Has anyone experienced probs with the TS files captured by the Colossus 2? I had trouble reading the files into video editing programs such as Vegas Pro 16, VideoRedo, and others. VLC and Windows media center couldn't play them either.
All the caps so far have been DirecTV via HDMI.
At first I used ffmpeg to try to demux the audio/video tracks, then read them separately into Vegas Pro. I could read them OK, but there were huge A/V sync errors.
I used ffmpeg again the to do error checking on the file (the old null output file trick: ffmpeg -v error -i Colossus2_Cap_.TS -f null - 2>error.log). The error log was huge and included messages:
SPS unavailable in decode_picture_timing
non-existing PPS 0 referenced
co located POCs unavailable
error while decoding MB 54 9, bytestream -18
Number of bands (57) exceeds limit (47).
m #0:1: Invalid data found when processing input
channel element 2.14 is not allocated
m #0:1: Invalid data found when processing input
Through ham-fisted trial and error with VideoRedo 5 and TS Doctor 2.1 I found that the only way I could reliably play or edit these files was to first use the "QuickStream" fix in VideoRedo. I can use the resulting .h264 MP4 output from that in the players and Vegas Pro. The VideoRedo log had input file specs and included these errors:
Video resync frames removed: 120
Audio resync frames removed: 202
The only thing I know about these messages from ffmpeg and VideoRedo is that they were reported as errors. Without the VideoRedo Quickstream fix I'd have no idea how to even approach fixing the captured TS files. So far (over a week) Hauppauge support has been silent over the issue.
Anyone else had anything remotely like these problems working with Colossus 2 captured files? Is there maybe a better way to fix the files than Quickstream?
Thanks for your time,
Last edited by SHS; 13th Dec 2018 at 10:11.
Bomoon, I also run my captured files thru tsdoctor to check for errors before editing in VRD5. Does it give you the AC3 streamID is not correct warning? After that I never get any errors importing into VRD & editing. Sometimes it removes a few sync frames like you listed but the files are always good.. You could also try tsMuxeR to try & fix any issues before editing..
I used TS Doctor 2.1 for the analysis. I didn't get any AC3 errors that I noticed in the log. Once again log file was huge. Here's a sampling of what was in there:
S ERROR : Packet 05223101 with 36 missing bytes
Resync found for packet 05223102 with Offset: -36
Found 2 fill packets at end
TS ERROR : For PID 0000, invalid packet 0287F0C1! Error: sync_byte_error
TS ERROR : Packet 0287F0C0 with 132 missing bytes
Resync found for packet 0287F0C1 with Offset: -168
Starting at packet 00000044 PCR: 00:00:00.000 (-00:00:00.000)
TS ERROR : Packet 02228AE4 with 112 missing bytes
Resync found for packet 02228AE5 with Offset: -112
TS WARNING: For PID 1011 01:01:10.252 TS packet 02228AE6: Packet discontinuity last=7 , current=13
TS WARNING: For PID 1100 01:01:10.252 TS packet 02228AF1: Packet discontinuity last=11 , current=1
PES ERROR : For PID 1100 01:01:10.352 PES packet 00029FFE is invalid (SizeMismatch), starting with TS packet 02228A37 Size: 698 should be 530
TS ERROR : Packet 02239310 with 56 missing bytes
H264 filler data: 8.2% [netto]
Cutted packets at the beginning: 68
Cutted packets at the end: 2
Discarded packets (filler data): 7073558 = 8.2% [brutto]
Discarded packets (not needed): 349132
Discarded invalid packets : 7
Previously I had already found that Demuxing or Recoding this file didn't fix all the problems shown in the log. The only difference was that I was able to read the file with VideoPro 16 and see both video and audio tracks. However they were badly out of sync everywhere I looked in the timeline, and the offset in time/frames increased over time. I don't know if the increase was linear or not, but the fact that it changed over time made it impossible for me to fix by moving the different tracks around on the timeline.
I haven't gone any further than that with TS Doctor. That's not to say that I won't ever get AC3 errors with the Colossus 2 output files. I'm going to have to keep experimenting to find a reliable, consistent way to fix these files.
VideoRedo QuickStream fix has always worked so far, but I have no idea what it's doing. I don't like the black box approach because if VideoRedo ever goes away and/or stops working, I'll be out of options.
Thanks for your time,
Alan what are you recording from cable/sat/pc ? and do have HDMI splitter and are you fix or auto resolution form that source
The source so far has been a DirecTV Genie, so the content resolution varies - typically 720p, 1080i, 1080p.
There is an HDMI switch (straight-through as far as I know) and a distribution amp/splitter downstream (also straight-through as far as content is concerned). When I was first setting things up I used direct connections. There was no change "that I could see" when I added the switch and distribution amp.
I'm using WinTV 8.5 to do the capturing. There isn't an "auto" setting for resolution that I can find, but in the capture settings there's a "Video Resolution" option which is set to "Native". The unused settings are 480, 576, 720, 1080 - never used any of those, at least not intentionally. From experience I've seen 720p, 1080i, 1080p in WinTV. Mediafile corroborates the resolution in the output file, i.e. I don't think there's any re-encoding going on during capture.
The audio is usually 2 chan AAC LC : Advanced Audio Codec Low Complexity
I'm not sure I answered your questions with the right info, I'm swinging blind here. Let me know if you need more info.
Thanks for your time,
PS: is your website active? I tried clicking on the link at the bottom of your message and got one of those "This Domain is for Sale" parkers. I seem to remember reading and posting there years ago.
That what thought setup your DirecTV Genie, to a fix resolution 720p and have a lot less problem go in to video resolution uncheck all but 720p becuases any time you use auto resolution it can causes really goof thing to happing
No I close it a long time ago but I can be found on many forums like SageTV, Plex, NextPVR and Emby and so on.
If I understand this right (my problem), you suggest setting the DirecTV ouput resolution to fixed 720p? Or do you mean change the WinTV "Video Resolution" from "Native" to 720? Or both devices set to 720?
You have a good point about not using "Auto" resolution where possible. Along with the 720 settings, I'm also going to try setting the WinTV "Video Resolution" to 1080, and leaving the DirecTV video resolution settings alone. I just want to see if I can still get 1080i and 1080p from DirecTV to the Colossus 2 and WinTV.
I've got time. I'll check out those other forums too. I'd like to see what SageTV is all about. Plus, the Hauppauge capture cards seem to be works in progress, so the NextPVR forum might be a good place to look for other options if things don't work out with Hauppauge.
Thanks again for your time,
Yes that right set the DirecTV output resolution to fixed 720p or 1080i if that what you want but I have found that 720p is better across other device iPad or iPhone and even Android.
You won't get 1080p believe me I all ready tried even under sun even with Dishnetwork too it the same as well
Last edited by SHS; 13th Dec 2018 at 19:03.
Bomoon, I'll try to offer some tips but my setup is a little different. (similar but diff) I don't have a genie or Colossus 2 but I do have an older DTV DVR & Hauppauge PVR2 & Colossus 1. I also use the hauppauge capture app to capture .ts files not win tv.. Are you capturing to .ts files? Is your genie set to output dolby digital? I assumed ac3 earlier but you said it's usually aac...? Either way, your captures are out of sync.
As far as I understand, If there's any type of corruption in the stream, It will cause invalid data packets in your capture. Sometimes throwing the time codes out of sync.
tsdoctor, VRD QSF & tsmuxer will usually fix these broken time codes. I use tsdoctor to ID the problem areas. (i.e. Packet discontinuity) TSdoctor usually makes my files usable to drop into VRD for editing. While using VRD, my files are in sync. If you want to try tsmuxer, There's an automatic setting to "insert SEI data if absent". Which is rebuilding the time code when it's missing. Just choose 'ts muxing' for the output.
Last edited by mocarob; 13th Dec 2018 at 18:38.
mocarob it causes auto resolution if steam switch from one resolution to another in mid steam the HD-PVR encoder wasn't design to handle those type of steam which is uselee where the problem come from.
Use lee when record from reg movie channel like HBO you don't see the problem