Reply to thread

Message

<blockquote data-quote="Snoopy87" data-source="post: 1100350" data-attributes="member: 128461">Ok, I will look with Sysinternals Process Monitor, to check if there is any other process accessing the file.Is there anybody who is using a multiseat setup with Windows 8.x as server and client? Because I think this is not a WS2012 R2 issue. I found out, that WS2012 R2 (which is based on W8.x) and Windows 8.x are using a newer SMB version: 3.0. So it could be a SMB problem with this newer version.I will also try another RTSP port, because with the default port I can't use RTSP because it shows glitches all the time and so it is impossible to watch with RTSP. Do you all (multiseat users) using RTSP or UNC? And don't have any issues?If there is no other process accessing the file, it seems it is a SMB 3.0 issue or a TSWriter issue (as said, the error only occur with the file part TSWriter is writing to, it does not happen with any other file or any other timeshift part file from the same recording).I also found out, that the error occurs at the byte position where TSWriter is writing to. So when TSWriter starts, it creates e.g. a 250 MB timeshift file and begins to write into it. If I directly try to copy the file with Windows Explorer, the error is thrown directly at the beginning. If I wait 10 minutes and try to copy the same file again with Windows Explorer, the file will be copied until it reaches the filestream position where TSWriter is currently writing to, e.g. at 100 MB. This is reproducable. Is the way TSWriter is creating the filestream and writing to it, definetly correct? Are all share flags set, so that another process (in this case TSReader, MediaPortal.exe) is allowed to read the through network access?</blockquote>

[QUOTE="Snoopy87, post: 1100350, member: 128461"] Ok, I will look with Sysinternals Process Monitor, to check if there is any other process accessing the file. Is there anybody who is using a multiseat setup with Windows 8.x as server and client? Because I think this is not a WS2012 R2 issue. I found out, that WS2012 R2 (which is based on W8.x) and Windows 8.x are using a newer SMB version: 3.0. So it could be a SMB problem with this newer version. I will also try another RTSP port, because with the default port I can't use RTSP because it shows glitches all the time and so it is impossible to watch with RTSP. Do you all (multiseat users) using RTSP or UNC? And don't have any issues? If there is no other process accessing the file, it seems it is a SMB 3.0 issue or a TSWriter issue (as said, the error only occur with the file part TSWriter is writing to, it does not happen with any other file or any other timeshift part file from the same recording). I also found out, that the error occurs at the byte position where TSWriter is writing to. So when TSWriter starts, it creates e.g. a 250 MB timeshift file and begins to write into it. If I directly try to copy the file with Windows Explorer, the error is thrown directly at the beginning. If I wait 10 minutes and try to copy the same file again with Windows Explorer, the file will be copied until it reaches the filestream position where TSWriter is currently writing to, e.g. at 100 MB. This is reproducable. Is the way TSWriter is creating the filestream and writing to it, definetly correct? Are all share flags set, so that another process (in this case TSReader, MediaPortal.exe) is allowed to read the through network access? [/QUOTE]

Verification