Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CountryBumkin]

When I'm watching recorded TV (.ts format) on my "weak" client machine, a 30 second jump forward causes the show to pause for 35 seconds (no exaggeration) before the picture starts playing again.
This machine has a JRmark of 448 (Intel Atom 330 with ION GPU). All of my other clients can jump through 30 seconds of show in about 4 seconds.
So the 30 sec jump ahead takes longer than just watching the commercial straight through.

I am running WIn7, RO Standard, ver .161. Just updated nVidia to latest version, all the movies/shows playback fine - its only jumping forward that has the long delay.
But I can jump 30 seconds on a mkv file (a DVD TV show) in 3 to 4 seconds, it's just the .ts files which are OTA recorded that has a problem.

I recorded a log from two client machines (one with the delay and one jumping correctly) and compared them but could not find anything obviously wrong/different between the logs. I can send a log if you want.

[Matt]

Are you playing from a network drive?

If nevcairiel sees this, is it possible .TS files are being read in little chunks?  Some network file systems get a couple of orders of magnitude slower when reading small chunks (say < 1024 bytes) at a time.  Or is it seeking more than it would have to?

We might also be able to put our multi-threaded buffered file source in front of the splitter and see what happens.

[CountryBumkin]

I am playing off a network, but my other clients are on the same network and they are jumping properly/quickly on the same files.

Could this just be due to the weak processor/gpu on this machine?

[Matt]

Would you be willing to copy a TS file to a local drive and test that?

It'd be nice to figure out if it's from the NIC/LAN or the CPU.

Thanks.

[CountryBumkin]

Of course.
I'll post back in a couple of minutes.

[CountryBumkin]

Matt you're brillant.
I copied the .ts file to the client and it now jumps 30 seconds in less than a second. So it is network related somehow.

Any idea what I can check next?

The network is a hardwired Cat5 - the file transfer speed (copying .ts from server to client) was 11.2MB/sec. Seems low for a 100MB/sec network - but it does play back okay (as does 1080p material).

[Matt]

This is progress.

Are you playing on a Library Server client, or just directly from a mapped network drive?  What's an example filename in Media Center?

I'm trying to figure out who is doing the file I/O -- our network reader, LAV source/splitter, or something else.

[CountryBumkin]

I'm playing on a Library Server client.

The file I tested on is called "Mike & Molly 2012-05-28.ts
The path shown in MC is "E:\TV Recordings\Mike & Molly 2012-05-28.ts" (where E:\TV Recordings is located on the server). I have no local files stored.

[Scolex]

The network is a hardwired Cat5 - the file transfer speed (copying .ts from server to client) was 11.2MB/sec. Seems low for a 100MB/sec network - but it does play back okay (as does 1080p material).

Just a FYI when they refer to network speed specs it is Mb (bit) not MB (byte) so if you were getting 11.2MB then that is actually quite good when you consider a hypothetical limit of
12.5MB this limit does not account for overhead. Overhead being the communication packets that get sent back and forth as a sort of receipt system.

[Matt]

Please test this again with the next build.

A data shortfall in the internet reader could cause 100% CPU usage on one core, and this would be enough to bury an Atom.

This issue will be fixed next build.

[CountryBumkin]

Thanks for looking into this. I'll key an eye open (for .164 I assume) and post back.

[CountryBumkin]

Matt,
the changes you made did not fix the problem. I now see a "buffering" message at opening but the 30 sec jump time is still the same.
The CPU is running pretty hard like you said - looks to be in the 70-75% range but I didn't see it peg during the jump.

As I mentioned before, this issue does not occur on ripped DVD TV shows, its only in my OTA recordings in .ts format (which are larger files, higher bit rate).



The screen shot was taken while the 30 second jump was occuring.

[InflatableMouse]

I'm thinking maybe the TS files require such a demand from the CPU to play, there is not enough time for the CPU to handle network traffic.

That would explain why a simply copy is fast, since there is nothing else going on.

Simple things to check:
Is your CPU always that high during playing a file, or only while streaming?
How does the CPU look when you play another file type that does skip properly?
Do you see your network load change (higher, lower) when a TS file is playing compared to when you skip 30 secs or does it remain the same?

[Matt]

I think currently the player can think it's in data starvation mode when it really isn't, leading to troubles on slower machines.

We're working on this now, and hopefully a coming build will improve the situation.