Stream cuts after 10 minutes consistently (USB) about sysdvr HOT 20 CLOSED

Been looking into this, probably found the issue but not quite sure. Can someone test this build of the last commit ? I managed to stream ~15 minutes without issues, don't have time rn to do longer testing.

from sysdvr.

I got that error during testing when my pc had some trouble reading my switch, can you try restarting your switch (and make sure the system module is running)?

from sysdvr.

Were you streaming when this happened ? For how long ? Can you reproduce this ? After this happen does just relaunching the stream work ?
Another user says the stream consistently closes after about 10 minutes, this could be related.

from sysdvr.

Yes, I was streaming for 10 minutes. It consistently closes after 10 minutes.

from sysdvr.

Welp sounds like a bug, will look into it.
Do you stream both audio and video ? Can you check if it happens anyway streaming both/only one ?

from sysdvr.

I streamed both Audio and Video, I tried with just video and so far it hasn't crashed yet. I'll try again with just audio and see the results.

from sysdvr.

I tried with just Audio and so far it hasn't crashed yet. It seems to be with Audio & Video only.

from sysdvr.

I tried video alone and I'm running into the same issue. After 10 minutes of streaming.

UsbStream video mpv ./mpv
UsbStream - 1.0 by exelix
https://github.com/exelix11/SysDVR

Fatal error. Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

   at LibUsbDotNet.NativeMethods.UnrefDevice(IntPtr)
   at LibUsbDotNet.NativeMethods.BulkTransfer(LibUsbDotNet.DeviceHandle, Byte, Byte*, Int32, Int32 ByRef, UInt32)
   at LibUsbDotNet.NativeMethods.UnrefDevice(IntPtr)
   at LibUsbDotNet.NativeMethods.BulkTransfer(LibUsbDotNet.DeviceHandle, Byte, Byte*, Int32, Int32 ByRef, UInt32)
   at LibUsbDotNet.Device.ReleaseHandle()
   at LibUsbDotNet.LibUsb.UsbEndpointBase.Transfer(IntPtr, Int32, Int32, Int32, Int32 ByRef)
   at System.Runtime.InteropServices.SafeHandle.InternalRelease(Boolean)
   at LibUsbDotNet.LibUsb.UsbEndpointBase.Transfer(System.Object, Int32, Int32, Int32, Int32 ByRef)
   at System.Runtime.InteropServices.SafeHandle.Dispose(Boolean)
   at UsbStream.UsbDevStream.Read(Byte[], Int32, Int32)
   at System.Runtime.InteropServices.SafeHandle.Finalize()
   at System.IO.Stream.Read(System.Span`1<Byte>)
   at UsbStream.Program.<StreamLoop>g__ReadToSharedArray|14_1(<>c__DisplayClass14_0 ByRef)
   at UsbStream.Program.StreamLoop(IOutTarget, UsbStream.UsbDevStream, StreamKind)
   at UsbStream.Program+<>c__DisplayClass16_0.<Main>b__1()
   at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.ThreadHelper.ThreadStart()

from sysdvr.

i get the same thing as well.

from sysdvr.

Same thing here with video on TCP and audio on MPV.

from sysdvr.

Just confirmed that it happened on TCP video with no audio. You can see this at about 29:45 in.

from sysdvr.

With tcp you mean still through usbstream right ? Anyway this is pretty much conformed now, added a warning in the release, and will fix as soon as possible

from sysdvr.

Yes, the TCP option in USB. The exact command I'm running is .\UsbStream.exe video tcp 6688.

from sysdvr.

excelsior.. Seems to cut around the one hour mark now? Was just doing a stream using OBS to youtube.

Honestly if there's a one hour cap then that's way better than 10 minutes. The build works well!

from sysdvr.

This sounds annoying to debug now, also really not sure of what could be the issue, i assumed it was the UsbLib context getting destroyed and that seems to have somehow delayed the issue 🤔 guess will have to check libusb code.
Btw that build also adds two debug options: --usb-warn and --usb-debug, next time you stream try launching with one of those, in case it fails you can save the log. debug is more verbose but could reduce performances depending on the computer, warn should just print warnings once in a while.
Looking at your screenshot it seems that only the video thread is failing, also no error message was printed, was audio still working ? Other users had a specific error message, maybe it's not the same bug, if it happens again try opening the home menu, waiting a bit and resuming the game.
I updated the build on the other message to print a warning whenever one of the streaming thread crashes (which does not look like your case)

from sysdvr.

I used the warn and debug args and was able to get an 3+ hours of recording with a problem. I stopped it myself around that mark.

And yes, previously when running the debug build via usb, audio was still being streamed while the video had crashed.

from sysdvr.

So does that screenshot include the log of the bug ? Only thing i see are two timeouts from usb reading, which could mean different things.
The 10 minutes crash had this log:

libusb: debug [libusb_exit]
libusb: debug [libusb_exit] destroying default context
libusb: warning [libusb_exit] some libusb_devices were leaked
libusb: warning [libusb_exit] application left some devices open

If you don't see that it's not the same bug and from what we know it could be even in the sysmodule itself.

from sysdvr.

Oh no, there was no bug at all. I stopped the stream when I pushed another payload at about the 3 hour mark. It was working perfectly fine when I turned on the verbose arguments

I'm not sure what could've given me the error I reported beforehand though.

Streamed for another 2 hours today, and no issues at all. I'm not sure what my first error from using the debug build was about. All of a sudden, no issues.

from sysdvr.

Likely some precise timing desync with the sysmodule, will increase the wait time so the sysmodule will timeout as well in case it happens again

from sysdvr.

Version 2.0 with a fix for this was just released

from sysdvr.