videos stop buffering / playing

[9001]

Hello, I also encountered this issue.

Version: copyparty-sfx.py v1.15.8

Browser: Microsoft Edge

Steps to reproduce:

1. Click on a long video to preview and watch for a while.
2. Then drag the progress bar to the middle and wait for a while, the video fails to load.
3. At this point, previewing this video or any other video results in a loading failure.

Originally posted by @BlueHtml in #71 (comment)

[9001]

sorry for the inconvenience @BlueHtml but I moved this to a new issue, since I believe the underlying issue is different.

this is curious... I have not been able to reproduce this, but I have some ideas.

if you have many images or videos in the folder, then the web-ui might be trying to load all the thumbnails. As the web-browser limits you to only 6 open connections to one server, this will quickly prevent performing any other actions until the thumbnails have loaded. And if the server has to generate the thumbnails, then this may take a while. When you seek in the video, the video player will disconnect and reconnect to request another range of the video for playback, and this would then not be possible until the browser has gone idle.

does this idea sound plausible? we can test this easily by making sure that all thumbnails have loaded, and then try to play the videos. If the videos are still buggy, then that's not it.

if this is not the reason, then i have some questions:

• are you connecting directly to copyparty? or do you have some sort of proxy or reverse-proxy (apache, nginx...) between copyparty and your web-browser?
• what is the file extension of the videos?
• what is the video codec? if you have enabled file indexing and analysis with global-options -e2ds -e2ts then this should be visible in the file listing, inside the Vc column. But you can also check this with ffprobe or mediainfo or similar, if you do not plan to enable indexing with copyparty.
• if you are familiar with the browser devtools, could you check whether the browser is keeping many connections open in the background for some reason? this can also be checked in the copyparty server log while the issue is occuring.

if you would like to share the copyparty server log so we can look at this better, then perhaps run copyparty with --log-conn --no-htp --log-thrs=5 -lo=copyparty.log to include more information about tcp connections. Please censor any filenames you would like to hide, but don't remove or reorder any requests or timestamps :>

[BlueHtml]

After executing the command python copyparty-sfx.py -c cp.conf, directly opening http://127.0.0.1/xxx.mp4 still results in playback failure.
The cp.conf file contains these three parameters: e2d qr hist: ./.hist

Browser devtools as shown in the image:

Copyparty logs as shown in the image:

[BlueHtml]

@9001 Hello, how do you use --log-conn --no-htp --log-thrs=5 -lo=copyparty.log? When I use it, it fails to start.

PS D:\tp\ss\jj> python copyparty-sfx.py -c cp.conf -v C:\down:/:r:rw,foo -a foo:bar --log-conn --no-htp --log-thrs=5 -lo=copyparty.log

[SFX]    this is: copyparty 1.15.9
[SFX]  packed at: 2024-10-18, 23:46:58 UTC, 1729295218
[SFX] archive is: D:\tp\ss\jj\copyparty-sfx.py
[SFX] python bin: D:\soft\install\python\python.exe
[SFX] python ver: CPython 3.12.0 (tags/v3.12.0:0fb18b0, Oct  2 2023, 13:03:39) [MSC v.1935 64 bit (AMD64)]

[SFX] found early
[SFX] jinja2: 3.1.2
[SFX] pyftpd: bundled
[SFX] sfxdir: C:\Users\1\AppData\Local\Temp\pe-copyparty

copyparty v1.15.9 "fill the drives" (2024-10-18)
  CPython v3.12.0 on Windows64 10.0.19045 [MSC v.1935 64 bit (AMD64)]
   sqlite 3.42.0*1 | jinja 3.1.2 | pyftpd 1.5.10 | tftp 0.4.0

copyparty: error: unrecognized arguments: .log

[SFX] retcode 2
[SFX] *** hit enter to exit ***

[9001]

When I use it, it fails to start.

that's curious! it looks like windows (or maybe PowerShell) is messing up the command somehow. But that is fine, you can use this instead:

--log-conn --no-htp --log-thrs 5 -lo copyparty.log

directly opening http://127.0.0.1/xxx.mp4 still results in playback failure.

nice, thank you for confirming that. I have started downloading that copy of frieren to see if there is something odd with the file encoding. So far the magnet isn't seeing any seeds, so let's give it some time.

(Himmel the hero would use DivX...)

[BlueHtml]

@9001 Hello, I executed the new command you provided, python copyparty-sfx.py -c cp.conf -v C:\down2:/:r:rw,foo -a foo:bar --log-conn --no-htp --log-thrs 5 -lo copyparty.log. The generated copyparty.log is attached: copyparty.log

Browser devtools as shown in the image:

[9001]

Thank you; this is interesting. Every time you seek in the video, the browser tries to download the first 1 MiB of the file. The request from the browser includes a caching directive to only return data if the file has been recently modified. As that is not the case, copyparty replies with an empty "HTTP 302" like it should, and this seems to confuse the browser... It just sits there doing nothing, and then disconnects after 2 minutes.

I have installed zh-cn_windows_10_business_editions_version_22h2_updated_oct_2024_x64_dvd_52bd0537.iso in a VM and tried to reproduce the issue with [Sakurato] Sousou no Frieren [01][AVC-8bit 1080p AAC][CHS].mp4, but unfortunately everything works as intended for me. So I hope you are willing to help debug this for a bit longer :-)

There are a few things I would like to try. I have attached a debug build which will help us: copyparty-sfx.py.zip

Let's test this first;

python copyparty-sfx.py -c cp.conf -v C:\down2:/:r:rw,foo -a foo:bar --log-conn "--ihead=*" "--ohead=*" --k304 2 -lo copyparty-k304.log

the "--ihead=*" "--ohead=*" makes it log all HTTP headers in both directions, so we can study the caching directives. And, more importantly, the --k304 2 will make copyparty disconnect the TCP connection immediately after sending a "HTTP 304" response. I doubt this will help, but I am very curious to see the copyparty-k304.log regardless!

Another thing we can try, is to ignore the caching directive from the browser, and always return the data anyways. This is very wasteful, but it should definitely work:

python copyparty-sfx.py -c cp.conf -v C:\down2:/:r:rw,foo -a foo:bar --log-conn "--ihead=*" "--ohead=*" --no304 2 -lo copyparty-no304.log

Could you please give these two a try, and share the logfiles? Note that they will contain a lot of headers, so please take a quick look and see if there is anything you would like to remove 🙏

Sorry for the trouble! I hope you are as curious as I am to figure this out 😁

[9001]

huh, I wonder if these two requests in the devtools are these two from the logfile... copyparty says it sent the whole file in response to the 2nd request, but msedge says it only downloaded 2.1 MiB.

I don't know what to make of this yet, but it is weird.

EDIT: could you please do a quick check with chrome and firefox? Just to see if you encounter the issue with those browsers too? I would like to make sure that this isn't an msedge bug...

[BlueHtml]

@9001 Hello, I copied the two different commands you provided and executed them. Then, I used Chrome to access it. Below are the logs and screenshots.

python copyparty-sfx.py -c cp.conf -v C:\down2:/:r:rw,foo -a foo:bar --log-conn "--ihead=*" "--ohead=*" --k304 2 -lo copyparty-k304.log: copyparty-k304.log

Chrome devtools as shown in the image:

python copyparty-sfx.py -c cp.conf -v C:\down2:/:r:rw,foo -a foo:bar --log-conn "--ihead=*" "--ohead=*" --no304 2 -lo copyparty-no304.log: copyparty-no304.log

Chrome devtools as shown in the image:

The content of the cp.conf file is as follows:

[global]
  i: 0.0.0.0
  p: 80
  theme: 7
  lang: chi
  e2d
  qr 
  hist: ./.hist

[accounts]
  username: password # username: password  这里可以自己定义决定了谁可以读写文件

[9001]

okay, I think I have some good news...

I noticed that copyparty is returning Content-Length headers in HTTP 304 replies. This is not illegal, but it is also not very common, so it might confuse some software.

Could you please try this beta and see if it fixes your issue? no-304-clen.py.zip

The following should be sufficient. If it still does not work, please include the log.

python3 no-304-clen.py -c cp.conf -v C:\down2:/:r:rw,foo -a foo:bar --log-conn "--ihead=*" "--ohead=*" -lo copyparty-nolen.log

If that does not fix the issue, please also try the following:

python3 no-304-clen.py -c cp.conf -v C:\down2:/:r:rw,foo -a foo:bar --log-conn "--ihead=*" "--ohead=*" --no304 2 -lo copyparty-no304-try2.log

Thanks again for helping track this down 🙏

one last question -- is it possible that you have some browser extensions, or maybe some proxy settings, which could be causing this issue? I'm just really curious what's going on since I am unable to reproduce it myself.

[9001]

this issue should be fixed as of v1.15.10

if you still encounter this behavior, you can try visiting the URL /?setck=no304=y&cc to force-disable caching.

if that fixes the issue, I would like to know as much information as possible about how you run copyparty, and how you access it.