New native recording patch

[rkoppelman]

Originally Posted by donkey

We didn't test with a Windows 7 x64 machine, so didn't find the problem, could you post a MpegDeMux.log? I check if there is a quick fix.

WHAT. I cant believe this. Windows 7 x64 is the majority of the market and it isnt tested!!

I dont want to be rude but i almost fel of my chair!

[gplasky]

Originally Posted by rkoppelman

WHAT. I cant believe this. Windows 7 x64 is the majority of the market and it isnt tested!!

I dont want to be rude but i almost fel of my chair!

Sage isn't the only app out there not officialy sanctioned for Windows 7. But it runs on Windows 7. And they're working on it and the beta patch gives you access to all the native Windows 7 decoders. I'm not sure this a "fall out of your chair" issue. It's just like all the Mac apps didn't support OS X and some still don't. But they're working on it.

Gerry

[Taddeusz]

Originally Posted by rkoppelman

WHAT. I cant believe this. Windows 7 x64 is the majority of the market and it isnt tested!!

I dont want to be rude but i almost fel of my chair!

I wouldn't say that Windows 7 x64 is the majority of the market. Maybe in the computer enthusiast community but not the public at large. I'm sure most computers are still shipping with a 32-bit OS.

[babgvant]

Originally Posted by Taddeusz

I wouldn't say that Windows 7 x64 is the majority of the market. Maybe in the computer enthusiast community but not the public at large. I'm sure most computers are still shipping with a 32-bit OS.

I wouldn't even go that far. Many HTPC users (like me) think x86 is a better platform choice.

[Rico66]

Originally Posted by Taddeusz

I'm sure most computers are still shipping with a 32-bit OS.

Actually that's really changing now. If you look at OEMs like Dell you'll notice that 64bit has become the default for many models. Considering that most new PCs have more than 3GB of memory, it's a logical choice as well.
But yes, it'll take some time until the majority moves to x64.

[Fuzzy]

NEW computers are mostly shipping with 64-bit now... the reasoning is that they are all shipped with 'new' hardware. 64-bit driver support is REQUIRED now for WHQL certification, so the number one reason to avoid 64-bit in the past (driver availability) is a non-issue on a new machine.

[Straykat]

Something odd is going on with M2TS import scans and it has something to do with Update 10 DShowplayer.dll

Problem: new M2TS files (ripped BD backups) are taking an impossible amount of time to scan and import. Were talking about many hours for 1 M2TS file.

Symptom: Scanning for new files hangs on the first new M2TS file is finds, locks both CPU cores at ~50% (Core 2 duo running @ 3.12), takes up 50% of my GB LAN (files are on a NAS), and doesn't stop for hours. Native.log shows that it starts parsing the file and keeps going without reported error.

Solution: I narrowed it down to DShowplayer.dll. Reverting to the last known .DLL from July or so, allows the M2TS files to be scanned, imported, and displayed within 5 seconds.

When I want to put new M2TS files on the storage:
1) I revert to the old Dshowplayer.
2) Start Sage and do a media scan.
3) Check to see that the movies are showing
4) Stop sage
5) Change the DShowplayer to the newer, Update 10 version
6) Restart Sage

[sdsean]

Just wanted to note that I finally got around to trying the beta demuxers that are here. ..

I still have the same problem . . . H.264 with EVR (on my ATI HD4890 video card, Win 7 Ultimate 64Bit) works just fine.

But with MPEG2/DVD/FlashVideo, the OSD flickers every single time there is an update in the OSD (like when it repaits to display the updated seek time).

[jerryt]

I have a (Windows 7) Sagetv v6.6.2 server and (Windows 7) Sagetv v6.6.2 client running the v10 of Native Recording Patch.

Please help
The Problems
1) I have a problem where requesting a live channel on the client takes 19 seconds for video to start. Also had the same problem when the server was running Vista.

2) Also I can watch H.264 source (Dishnet\HD-PVR) and then MPEG (OTA\HDhomerun or M780), but after watching MPEG source the first selection of a H264 source results in plackback exception (-1,0x800401f0). Have to restart Sagetv client application to watch H264 again.

Recordings don't have the 19 second video delay, but the playback exception problem is the same for live or recordings.

All suggestions welcomed !!!

Problem developed when the client was upgraded to Windows 7 and the Native Recording Patch was installed. I have not tried earlier versions of the patch.

[Taddeusz]

Originally Posted by jerryt

1) I have a problem where requesting a live channel on the client takes 19 seconds for video to start. Also had the same problem when the server was running Vista.

I know it sounds silly but make sure the time on both client and server are identical. This will cause playback to start later than it should.

[jerryt]

Originally Posted by Taddeusz

I know it sounds silly but make sure the time on both client and server are identical. This will cause playback to start later than it should.

Unbelievable !! updated clock from the internet on both computers and the tune time when from 19 seconds to 6 seconds on H264 and 3 seconds on OTA MPEG.

Thanks I never would have figured that one out on my own.

Now to fix the playback exception ...?

[koan00]

Originally Posted by jerryt

2) Also I can watch H.264 source (Dishnet\HD-PVR) and then MPEG (OTA\HDhomerun or M780), but after watching MPEG source the first selection of a H264 source results in plackback exception (-1,0x800401f0). Have to restart Sagetv client application to watch H264 again.

I am not getting the same exception, but I am also having trouble switching between streams it seems..

[jerryt]

Originally Posted by koan00

I am not getting the same exception, but I am also having trouble switching between streams it seems..

FIXED - Was using AC3Filter for mpeg 2 audio, switched to Microsoft DTV-DVD Audio Decoder.

Very happy, switching between both formats without exception now.

[bmac.to]

Originally Posted by sdsean

Just wanted to note that I finally got around to trying the beta demuxers that are here. ..

I still have the same problem . . . H.264 with EVR (on my ATI HD4890 video card, Win 7 Ultimate 64Bit) works just fine.

But with MPEG2/DVD/FlashVideo, the OSD flickers every single time there is an update in the OSD (like when it repaits to display the updated seek time).

This sounds like an issue I have - the way I fixed it was to turn of animations in the OSD - not a great solution because the animations are nice. As far as I can tell from these forums, this problem is always related to ATI graphics.
________
Plymouth Satellite Specifications

[Ender]

I have one channel on my HDHR that will not tune in with Sage. It does show up just fine if I use The QuickTV application from Silicon Dust. This is with Windows 7, and the Native 10 files.

I have attached a few error logs and the scn, and frq files.

I do have another issue, where some recordings are corrupted, but I have not gotten around to looking at the error logs from those, it is so random that at the moment I am not sure if it is network related or not. I will check back later when I have more definitive logs of the broken recordings.

[Tiki]

I just installed the native patch today and did some testing.

My first test was playback of a 720p MPEG-2 file recorded with HDHomerun-QAM from CBS ("Ghost Whisperer") using the new Microsoft decoder. Playback was good, a little smoother and slightly lower CPU (~20% vs ~30%) than with the default Sage install and the Sage decoder with DXVA enabled.

My second test was playback of a 480i MPEG-2 file recorded with HDHomerun-QAM from History channel ("The Universe"). This was not so good. Playback was smooth and CPU was very low, but aspect ratio was not correct. The original file was letter-boxed widescreen - Sage inserted letterboxes and pillarboxes. My TV is 4x3 1080i, so no need to insert additional letterboxes or pillarboxes. I play everything back with aspect ratio set to Source.

I tried changing the decoder back to Sage Decoder, but it made no difference.

My third test I tried live playback on the History Channel ("Nostradamus Effect") again using HDHR-QAM. This is an SD channel and should be 480i, MPEG-2. It took about twice as long as normal to tune the channel, and I got a "No Signal" message from Sage for about 3-4 seconds (I've never seen this message before unless the HDHR was setup incorrectly). After the channel tuned, it had the same extra letterboxes and pillarboxes as seen with my recording of "The Universe". After about 2 minutes of watching, the picture and sound froze (but the UI remained responsive) and I noticed I was getting a red bar on the timeline, indicating part of the recording was missing. I was able to press Stop and then re-enter live TV and things went back to working (still with the extra letter and pillar boxes).

My fourth test, I tried live playback on AMC (some old western movie, don't remember title), again using HDHR-QAM tuner. This is an SD channel and should be 480i, MPEG-2. Picture was full frame 4x3 with no letter or pillar boxes, like it should be.

My 5th test, I tried live TV with MAX (Movie "Back to School"), this time using PVR-150 recording via RCA composite from STB in 480i - "DVD Standard Play" encoding profile. This also played correctly as full frame 4x3.



My only guess about the extra letter and pillar boxes, is that there must be some flag in the stream from the HDHR that is being misinterpreted by the TSSplitter or MPegdemux at least on the History Channel. Has anyone else seen this?

I have no idea why it is taking longer to tune channels - has anyone else seen this?

The "freeze" during playback could have been a fluke (maybe it was in the signal from the cable company) - I will have to monitor this some more...

I attached my native.log from this afternoon (I notice it mentions "ATSC" a lot, but I don't have any ATSC sources - only QAM for the HDHomerun and Composite for the PVR-150).

[Fuzzy]

Unfortunately, I think that may mostly be a limitation of QAM SD sources. They are generated at the cable head end, and, lets just say they get pretty sloppy as far as compliance goes. In theory, they are only really supposed to be watched on their cable boxes, which are very 'loose' as far as standards go. You chould try finding an MPEG-2 analyser and see what the stream is reporting.

[Tiki]

Originally Posted by Fuzzy

Unfortunately, I think that may mostly be a limitation of QAM SD sources. They are generated at the cable head end, and, lets just say they get pretty sloppy as far as compliance goes. In theory, they are only really supposed to be watched on their cable boxes, which are very 'loose' as far as standards go. You chould try finding an MPEG-2 analyser and see what the stream is reporting.

These files did play correctly in Sage before I installed the native patch, so it does have something to do with how the native patch is interpreting things (but I agree it could be that the cable co. is not marking the file correctly and the new patch is reading that flag, while maybe the old Sage stuff ignored it).

Do you have a recommendation for what to use to anylize the stream?

[Vaskill]

Originally Posted by Tiki

These files did play correctly in Sage before I installed the native patch, so it does have something to do with how the native patch is interpreting things (but I agree it could be that the cable co. is not marking the file correctly and the new patch is reading that flag, while maybe the old Sage stuff ignored it).

Do you have a recommendation for what to use to anylize the stream?

MediaInfo will tell you what you need to know about almost any container/stream and the media within.

[FlyingDoc]

Originally Posted by easperhe

All,

I'm using firewire recordings from Motorola DCH3200 boxes. My network encoder recording graph is using TSsplitter to convert STB transport stream to program stream. I downloaded update10 and installed. I also replaced TSsplitter with TSsplitter3 in my graph. After doing so, I get "no signal" on all stations. When I go back to TSsplitter, all works again. Is there some reason TSsplitter3 will not work for firewire recordings? Or am I doing something wrong?

Does anyone have an answer (or suggestion ) about this. I am doing the same thing and getting the same result. I want to save the firewire data as PS because this seems to improve comskip accuracy.