Print

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

[raym]

When I'm fast forwarding or rewinding the Timeshift buffer (CTRL + ARROW keys OR CTRL + SHIFT + ARROW keys), could the following please be done:

1. Mute the audio. In my case, I'm using SPDIF out to a receiver and I get bursts of audio during the seek. I don't get this with any other seek in any other video file. Note> this mostly relates to the CTRL + ARROW key seeking method rather than a JUMP seek (CTRL + SHIFT + ARROWs).

2. Show ELAPSED TIME / TOTAL TIME in the OSD. I've started a seperate thread for this as it also relates to normal video: http://yabb.jriver.com/interact/index.php?topic=41570.0 - Something like what you get when seeking in a DVD would be perfect.

Thanks.

[Yaobing]

We already try to mute audio during FF/Rew. It works when playing through renderers that decode to speakers. Somehow it does not work with SPDIF setup, and I have not figured out a solution yet.

I will work on the second suggestion when I have some time.

[raym]

Thanks Yaobing. I look very forward to this!

Regarding the muting issue, I wonder why I only hear these burst of audio when seeking the TS buffer though and not with any other video seeking?

[raym]

Here's another one...

During Timeshifting, is there some way of making sure playback is always at least a few seconds behind the live broadcast? I tend to have a lot of issues with stuttering playback and general slowness (Theater View animations etc) when playback "catches up" to the live broadcast. I think Vista MC does this and perhaps to combat this exact issue??

Thanks.

[raym]

We already try to mute audio during FF/Rew. It works when playing through renderers that decode to speakers. Somehow it does not work with SPDIF setup, and I have not figured out a solution yet.

I will work on the second suggestion when I have some time.

Hi. Just wondering if any progress has been made on this yet?

Re: muting with SPDIF, why would this only be a problem with DVB-T Timshifting? Ie, ff or rew a video or DVD with SPDIF happens beautifully - no bursts of audio at all. Generally, seeking the TS buffer still feels a bit "fragile" to me. It's seems a bit sluggish at times, compared with seeking other video formats. I guess the whole thing is much more processor intensive but another front end app (which shall remain nameless  ) seems to handle this fine on the same PC so, I don't know...

Re: the second point. If possible, I think the OSD should remain on screen for the duration of the seek - as long as the timers get updated of course 

Thanks.

[rpalmer68]

I have to say seeking in TS is slow for me too, sometimes takes a second or more to respond to a keypress, other video seeking (DVD, DVR-MS playback) is much more responsive.

It's also slow changing channels, and having looked at a log there seems to be a LOT happening whenever a channel is changed.   Any chance this could be sped up somehow?

Cheers
Richard

[Yaobing]

About channel changing speed:

I think I've got it as fast as I can. There is a lot going on when a channel is changed. This is particularly true if you are in time-shifting mode. In TS mode, channel changing requires a rebuild of the DirectShow graph that significantly slows down the process.

[raym]

Generally speaking, I think a lot of the channel change speed issues (with TS disabled) have to do with the type of card being used. I used to experience slow channel changes and have tried many different DVB-T cards until I switched to the DVICO's. For some reason (for me at least) these cards seem consistently more responsive in this area. With MC it only takes 1 or 2 seconds to switch from one channel to the next.

With TS enabled though, it's significantly slower (>5 seconds) and as described previously, the TS seek speed is still somewhat problematic for me.....

[raym]

Sorry to harp on this but I've noticed that the overall timeshifting performance has appeared to degrade somewhat with recent builds (currently on beta build 370) . When DVB-T development was underway, and I was looking at this area closely, I don't ever recall experiencing the kind of slowness I'm seeing now.

In summary, the issues I'm experiencing while timeshifting is in progress are:

1. Slow to respond to remote/keyboard keypresses
2. Slow, stuttering Theater View animations
3. Slower to switch channels. Ie, this was never lightning fast but is now taking at least 5 seconds. Note: Normal channel change speed is excellent for me when not timeshifting
4. Slow seek speed (as discussed in this thread). In combination with point 1, jumping around the TS buffer (30 secs forward, 10 secs back) has become far less than ideal. Again, this used to be quite good with older builds.

I wonder if anything's changed recently which may be contributing to some of these slow downs? I'm testing on the same PC I always have. Core 2 Duo, fast SATA II local disc, ATI x1600 video etc... No running virus checkers or other system hogs.

All other video playback is flawless.


In relation to this:

There is a lot going on when a channel is changed. This is particularly true if you are in time-shifting mode. In TS mode, channel changing requires a rebuild of the DirectShow graph that significantly slows down the process.

Is it possible to cache or build the graph in advance somehow, in readiness for when it might be needed?


Thanks.

[Yaobing]

Is it possible to cache or build the graph in advance somehow, in readiness for when it might be needed?

It is not possible to build a graph without knowing which channel you want to play. We need to know the format of the data (HD/SD, AC3/nonAC3 etc.).

[raym]

Thanks for the reply. Any thoughts on my other points though?

[Yaobing]

Thanks for the reply. Any thoughts on my other points though?

I do not know how to comment on those. I can not think of any changes that would cause performance issues. Have you saved (knowingly or unknowingly) a lot of time-shifting files? Is hard disk space an issue?

[raym]

I do not know how to comment on those. I can not think of any changes that would cause performance issues. Have you saved (knowingly or unknowingly) a lot of time-shifting files? Is hard disk space an issue?

I don't save TS files. Disk space is not an issue.

I guess I'm more interested to know how you personally find the performance of MC while timeshifting is in progress. Do you experience the same lags etc as I've described? What about any "uncomfortable" slowness when seeking the buffer (compared to the great responsiveness of other video playback)?

If I'm not alone, then is there any opportunity for improvement in this area?

Please understand that I'm not trying to be difficult or overly critical . Generally speaking, I'm extremely happy with MC's dvb-t support. However, I still find myself avoiding the whole timeshifting feature due to the performance impact it causes. If I was using a crusty old PC I would understand but I'm not.

Thanks again.

[JimH]

Please understand that I'm not trying to be difficult or overly critical . Generally speaking, I'm extremely happy with MC's dvb-t support.

raym,
Thanks, but you're always very helpful even when things aren't working for you.  If there is a problem, we'll try to find it.  We're very appreciative of what you've contributed to MC development.

[Matt]

raym,
Thanks, but you're always very helpful even when things aren't working for you.  If there is a problem, we'll try to find it.  We're very appreciative of what you've contributed to MC development.

Ditto.  Raym, you're great.  Simply great.

[Yaobing]

raym,
Thanks, but you're always very helpful even when things aren't working for you.  If there is a problem, we'll try to find it.  We're very appreciative of what you've contributed to MC development.

Ditto 2.

To answer your question, I myself have not experienced any slowness in TS, but I admit I have recently had little time watching TV, so the tests I have done have been short ones.

[raym]

Thanks for the kind words guys. It's a pleasure to contribute whenever and however I can. MC and everything it provides has easily become a passion of mine. To say I enjoy contributing to the development process would be a huge understatement.  

...I myself have not experienced any slowness in TS, but I admit I have recently had little time watching TV, so the tests I have done have been short ones.

Well that's the benefit I have of being a couch potato!    All jokes aside though, you make a valid point. My HTPC running MC is the only device I use for digital TV playback in my household. Therefore, the observations I've made are no doubt the result of the many hours spent using dvb-t in a "real" (non-test) situation.

As always, I'll continue to take note of anything that may help isolate the problem further.

Thanks again.

[rpalmer68]

Well that's the benefit I have of being a couch potato!    All jokes aside though, you make a valid point. My HTPC running MC is the only device I use for digital TV playback in my household. Therefore, the observations I've made are no doubt the result of the many hours spent using dvb-t in a "real" (non-test) situation.

Must be my problem too 

Richard

[rpalmer68]

I've got the wife is complaining that channel changing is SO SLOW now.

I used to use DNTVLive! for my TV playback, and with timeshift ON it takes a max of 3 seconds to change channels, while MC takes between 8 and 10 seconds every time.

So in case it's my setup (I have 4 tuners) I have captured a log of one channel change as there seems to be a lot logged for one change..

It's here;
www.thepalmers.com.au/temp_txfr/jrmc/TV_change.zip


Any ideas?

Cheers
Richard

[rpalmer68]

Yoabing,

Does my log show anything to indicate why channel changing is SO SLOW?

It really is noticable, everybody says gee it takes ages to change channels.

Thanks
Richard

[Yaobing]

Richard,

Your log file shows that it took 9.7s to switch channel. I would like to make it shorter, but I am afraid I can not do much about it. You actually fared better than I did with my KWorld PlusTV stick. I had to wait 11.7 seconds.

Here are the break down of what took so long:

0.3 sec intentional wait (I will not explain in detail except to say that this is needed, and is only a small amount).
2.7 sec to stop and tear down old graphs (most spent on stopping part - this is where the device drivers play a role).
0.3 sec to build new graph that write data to disk.
2.6 sec to run the graph (i.e. to get the device to start streaming data)
1.8 sec to have the first data sample streamed to the writer and written to disk.
1.0 sec to build player graph (there is some intentional delay here)
1.0 sec to start playing from the player graph.

As you can see, the major delay comes in stopping or starting a graph that involve the tuner device (bold face above). In each case only one function call is involved (and that function call blocks for nearly 3 seconds).

[rpalmer68]

Richard,

Your log file shows that it took 9.7s to switch channel. I would like to make it shorter, but I am afraid I can not do much about it. You actually fared better than I did with my KWorld PlusTV stick. I had to wait 11.7 seconds.

Here are the break down of what took so long:

0.3 sec intentional wait (I will not explain in detail except to say that this is needed, and is only a small amount).
2.7 sec to stop and tear down old graphs (most spent on stopping part - this is where the device drivers play a role).
0.3 sec to build new graph that write data to disk.
2.6 sec to run the graph (i.e. to get the device to start streaming data)
1.8 sec to have the first data sample streamed to the writer and written to disk.
1.0 sec to build player graph (there is some intentional delay here)
1.0 sec to start playing from the player graph.

As you can see, the major delay comes in stopping or starting a graph that involve the tuner device (bold face above). In each case only one function call is involved (and that function call blocks for nearly 3 seconds).

Thanks for that,

So how is other software doing it in 3 seconds while also timeshifting and using the same tuner?

Are there any directx utilities I can run to show what's happening with other software as the logs don't go inot as much detail, as MC?

Richard

[rpalmer68]

I've been thinking about the channel changing speed again ...

When Timeshift disabled itself the other day the channel changing was almost instant, but with timeshift enabled it's back to 6 seconds or so.

So what I was wondering, could all the timeshift closing/opening file I/O be done after the channel change?

This way the visual experience for the user isn't affected waiting for the disk I/O stuff to complete.

Just a thought.

Cheers
Richard