TV Issue with FastForwarding (1 Viewer)

[rich110]

Hi all,

I'm a recent convert to MP from MCE, and I can confirm that this problem definitely exists.

Basically skipping forward or back in MP has been very erratic from the start. A typical for me would be if I skip forward 1min, MP would actually jump Backward to a point in the recorded that we'd already just watch.

I never really could find an explanation for this behaviour, but after reading this post I began to take note of the length of the recorded tv program - and they are extremely erratic. I have one recording where this problem occurs which is 50min long (an SBS channel recording). In the main Recorded TV list is appears correctly as 50min long, but when I played the program on 3 different occasions, MP said the program was 1:14 hours long, 1:03:48 hours long and 1:03:48 hours long.

Is this an MP thing or a WMP thing? I recently updated to WMP11.

Also, I notice that most of the posters here are Australian. Could this have something to do with irregularities in some of our broadcasts? I know through my use of MCE that there are some channels that have non-standard formats in their broadcasts (there are some AC3 sound problems, etc).

I hope this problem can be identified and corrected as it is one of the only major stumbling blocks from me adopting MP as my main media center app. I could probably live with this issue but my wife cannot - and we all know they have the final say, right?.

Thanks
Rich


My setup:
MediaPortal Version: 0.2.2.0
MediaPortal Skin: B2 wide
Windows Version: XP SP2
CPU Type: AMD Opteron 156
HDD: Samsung 300 GB
Memory: 1 GB
Motherboard: Gigabyte GA-K8NF-9
Motherboard Chipset: nForce4
Motherboard Bios: -
Video Card: Nvidia GeForce 7600GT
Video Card Driver: 93.71
Sound Card: Auzentech X-Mystique 7.1
Sound Card AC3: SPDIF over Toslink
Sound Card Driver: -
1. TV Card: DNTV USB Tiny2 DVB-T
1. TV Card Type: DVB-T
1. TV Card Driver:
2. TV Card: DNTV USB Tiny2 DVB-T
2. TV Card Type: DVB-T
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: Nvidia Purevideo
MPEG2 Audio Codec: Nvidia Purevideo
Satelite/CableTV Provider: -
HTPC Case: Silverstone
Cooling:
Power Supply: Seasonic S12 500W
Remote: Logitech 880 (using MCE profile)
TV: Sony CRT
TV - HTPC Connection: VGA -> RGBHV

 

[TesterBoy]

Hi Rich110 - welcome to skipping-nightmare country!

I have confirmed (via a small program that I hacked together) that the problem is in the duration in the DVR-MS header - it matches the screwed length displayed by MP and WMP, to the second e.g. the 151+ hour recording I have contains 151+hours in the duration field in the header, although the actual recording is 35 minutes long.

It's not just an Aussie problem - MrPaulo and I are Kiwis...

 

[rich110]

Sorry TesterBoy (and Mr Paulo).... Aussie arrogance in not looking closely enough at the flag on your avatar (just assumed was oz flag).

I must edit part of my last post: The recognized duration of affected recorded tv files is not in fact variable as I originally said, but is actually consistently wrong. MP actually consistently says that the program I mentioned is 1:22:39 hours long (when it is actually 0:50 hours long).

WMP11 also lists this file as 1:22:39 hours long so I definitely agree with you that the DVR-MS header files must be incorrectly written.

Have any of the developers acknowledged this problem or given any indication that they can replicate it and possible fix it?

I'm running the stable v0.2.2.0... do any of the SVN updates fix this problem?

Cheers
Rich

 

[TesterBoy]

I'm running 2.2.0 too - don't know about SVN updates, but Peter Pan(!) has reported the same problem with the TVEngine (see the thread at https://forum.team-mediaportal.com/showthread.php?t=14304) so that won't help either...

I assume that since we haven't yet logged it in the Bugs forum, no devs are paying particular attention to it. I guess it's time we did.

 

[MrPaulo]

Hi Guys,

Peter Pan did start a thread in the bugs forum already:
https://forum.team-mediaportal.com/showthread.php?t=13944
which I updated to include more info as mentioned in this thread. He also confirmed that his skipping problem and this duration issue appear to be the same thing from his point of view as well. However no-one has further commented in there.

I'm not sure on the ins and outs of bug raising - is this the right way to go about it?

BTW - devs... I don't mean to gripe! I really appreciate all the great work that has gone into MP!!

 

[infinite.loop]

never had such an issue yet.
but one of the reasons why we moved away from the old tv-engine is that we used Microsoft SteamBufferEngine (which is creating these dvr-ms files).
Now the TV-Server has a brand new engine which is able to directly record mpg files or even ts files(transportstream)

i had other issues which dvr-ms recordings (didnt start to play with any player). a conversion to mpg always "fixed" this problem.

 

[MikeB]

Area: Media Portal Program
MediaPortal Version: 0.2.2.0 (2006-12-21)
MediaPortal Skin: BlueTwo
Windows Version: Windows XP (SP2)
.NET CLR Version: 2.0.50727
DirectX Version: 4.09.00.0904 (9.0c)
Audio Codec: MPA Decoder Filter
Video Codec: MPV Decoder Filter
CPU Type: Genuine Intel - T2400 @ 1.83GHz
Memory: 1 GB
Motherboard: 0FF049 (Dell Inc.)
TV Card Model: Hauppauge WinTV Nova-TD
TV Card Type: DVB
TV Card Driver: 3.3.24348.0
Video Card Model: Mobile Intel(r) 945gm Express Chipset Family (224 MB)
Video Card Driver: -
Video Card Resolution: 1440x900
Video Render Type: VMR9
Audio Card Model: SigmaTel High Definition Audio CODEC
Audio Card Driver: -
Synopsis:: Fast forward speed is incorrect

I have a similar problem when watching recorded TV (in this case not recorded with MP). Here, when I use the remote or F6 to fast forward, the banner at the top of the screen shows the timeline and 2x, 4x etc depending how often I press F6, but the playback accelerates much faster than that, as does the remaining time counter. I'd guess that it's going about 32x speed. I've attached a log: look around 10:22:10.

Mike.

 

[Paranoid Delusion]

DVR-MS files here correct lenght, using 0.2.2.0 without any svn.

I know it's a long shot guys, but the MS time update for your region is installed.

If you have, did the problem exist prior to that.

Surprised if there was a problem down your way, marcusb would have joined in with this one.

 

[TesterBoy]

I assume you're talking about the Australian Daylight Saving update? If so, I hope not - I'm in New Zealand B-)

Further info - the problem appears to go away after rebooting the htpc, but then progressively gets worse over time...

Compressing fixes the problem for a particular recording (since the header is then gone), but the problem also affects the timeshifting - obviously we can't compress the timeshift buffer. This makes the shuttle almost useless for watching live TV (Note that on my htpc at least, I can't turn timeshifting off since the picture and sound degrade very quickly until it stops completely).

Edit: Actually, I'm not sure it gets worse - I rebooted last night and the recorded time was correct (0:01:00), but this morning I'm getting a 0:03:44 time on a 0:01:00 recording. The 35-minute scheduled recording I made this morning thinks it's 45 minutes long, though...

 

[TesterBoy]

Old bugs found in Mantis...

I've just trawled through Mantis, and found

http://mantis.team-mediaportal.com/view.php?id=586 : Seeking recorded TV doesn't work properly

The report describes one of the symptoms we are experiencing - a recording duration far bigger than it should be.

The following report

http://mantis.team-mediaportal.com/view.php?id=603 : #TV.Record.current and #TV.Record.duration show wrong info

could also be related - we sometimes see a duration almost exactly twice the actual duration, although I can't tell from Mantis whether it was a precise, constant 2x (i.e. the fix was to divide by 2 B-) ) or just an approximation.

(Is there any way (apart from looking at all the updates from around the bug-closure time) to tell what actual changes fixed these defects?)