Skip and FF Differences Between Recordings and Video Library using Client

[melearp]

I guess that this might have been covered before. I did some searching and found an old reference here http://forums.nextpvr.com/showthread.php?t=19535. If someone knows a better ref then please tell me.

Using 98.13b in client/server mode. Server is a 3ghz athlon and client is 2ghz pentium. Both are running same GBPVR. Lan is wired. All is working fine --- except:

On the CLIENT:
If I watch a recorded programme via Recordings, then FF doesn't work most times (programme freezes) and skip forward or backward does work but is slow (about 4-6 seconds per skip). I copy the same file over to the Video Library directory, which I keep separate, and the very same file plays absolutely perfectly with a good working FF and near instant skip forwards and backwards.
FF is not set to do short skip.

On the SERVER:
All is well and everything works from either source.

Can I fix this or is it a known "feature".

(I am using SQLite).

[sub]

Its probably always going to be relatively slow skipping on the client, due to many of the Microsoft directshow components I'm using expecting fast disk access to the video file. When you press the skip button and it attempts to seek to another part of the file, behind the scenes, it can move the file pointer dozens of times, and process a huge amount of data while scanning to find the right point in the file.

It relates to MPEG files not being indexed, so there is no easy way to determine where in the file a specific timecode will be. So it ends up guessing and doing a binary search, reading and scanning big chunks of data as it goes, looking for the correct timecode in the stream. This all happens pretty quickly on a local machine where disk access is quick. Pulling this same info across the network is slow.

[melearp]

(I used to be a software engineer before I retired :-))

I understand what you say, but I don't understand is why it IS very fast on the CLIENT when viewing through the Video Library, but not when viewing through the Recordings (note both directories are on the same drive on the client). I am very tempted to postprocess and move all my recordings to the Video Library, but I would really like to understand why I am doing it!!

[K.S.]

is that behavior the same, regardless of client access mode (local share or streaming)? at least with streaming, that should not be the case... yeah, i now, with streaming you have the lag needed to fill up the buffer

[melearp]

I ahdn't considered streaming (forgot). It's in streaming mode at the moment. I will try with shared file mode later - my other half has the facilty at the moment and I can't disurb her.

[HtV]

I am very tempted to postprocess and move all my recordings to the Video Library, but I would really like to understand why I am doing it!!

You won't have to postprocess, all you have to do is add your recordings dir to the list of dirs in the video library. You do that in config-directories, on the server.

[sub]

at least with streaming, that should not be the case... yeah, i now, with streaming you have the lag needed to fill up the buffer

The streaming is at a file level, so yes it still effects streaming mode. ie, all the same logic is running as when you run it locally except that actual reads go remotely.

I guessing you're thinking the "seek to timestamp x" command is set to the server which takes care of it all. Thats not how it works. Its more like the client sends the "read x bytes from file location y", meaning all the work for seeking work is done at the client end. Its done this way for compatibility with the Microsoft Directshow components we have at our disposal for playback.

[K.S.]

The streaming is at a file level, so yes it still effects streaming mode. ie, all the same logic is running as when you run it locally except that actual reads go remotely.

I guessing you're thinking the "seek to timestamp x" command is set to the server which takes care of it all. Thats not how it works. Its more like the client sends the "read x bytes from file location y", meaning all the work for seeking work is done at the client end. Its done this way for compatibility with the Microsoft Directshow components we have at our disposal for playback.

ok, that's not really nice in regard of performance but i guess you have to stick to that if you don't have to much time to build your own streaming logic

well, in terms of performance, that means:
- streaming:
smaller bandwidth used due to UDP connection (no error correction for the connection, server just sends data packets... please correct me if i'm again wrong )
timelag with each skip because of "seek in file" logic)
additional timelag (1-2 sec depending on buffer size defined?) for each skip because of building up buffer

- local share:
more bandwidth used due to tcpip (error correction, rather useless for video) & smb protocoll overhead
timelag with each skip because of "seek in file" logic)

[melearp]

You won't have to postprocess, all you have to do is add your recordings dir to the list of dirs in the video library. You do that in config-directories, on the server.

Yes I understand that - it's just that this is less understandable for the users. I would have to retrain. That might be the way to go, but I don't like changing things for them unnecessarily. You lose credibility if things change all the time without any noticable user improvement.


And I've done the test with file sharing vs streaming. Yes, if I switch to file sharing then both Recordings and Video Library behave the same on the client - very fast skipping. I can hold down the forward skip and get to the end of an hours program in just a few seconds.

Does this mean that access via Video Library always uses File Sharing and it is only access via Recordings that is changed by the streaming setting?

I am now leaving it on File Sharing for the moment. It is fast and I get no noticeable drawbacks. Certainly no performance issues as suggested.