nschlia / ffmpegfs

FUSE-based transcoding filesystem with video support from many formats to FLAC, MP4, TS, WebM, OGG, MP3, HLS, and others.
https://nschlia.github.io/ffmpegfs/
GNU General Public License v3.0
198 stars 14 forks source link

frequently get ERROR : [R1_235_CC.png] Timeout reading image #36

Closed nschlia closed 4 years ago

nschlia commented 5 years ago

also i frequently get something like 2019-05-29 14:45:42 ERROR : [/home/zhukov/ffmpegfs/mummy/scans/R1_235_CC.png] Timeout reading image frame no. 4442: (110) Connection timed out

Originally posted by @zhuker in https://github.com/nschlia/ffmpegfs/issues/35#issuecomment-496902287

nschlia commented 5 years ago

Seems that sometimes the client requests an image that never comes (causing the time out). Actually ffmpegfs should seek to that image, decode and return it.

Is image no. 4442 some image and there are a few 100 or 1000 more, or is it one of the last, say, 1-5 images?

If it's one of the images in the middle of the file the positioning logic has a problem. If it's on of the last images then it may never come as the predicted number of images is larger than the real one. In that case the message is simply wrong.

nschlia commented 5 years ago

Added a lot of extra logging with these commits:

https://github.com/nschlia/ffmpegfs/commit/60b93c37fb889de87b15922478ffd9ae8e917487 https://github.com/nschlia/ffmpegfs/commit/51065aca310efed3f67901a1d1560325b5aaac8b

The logs should help me to figure out what's wrong. Multi threaded programming is like a box of chocolates. You never know what you're gonna get.

Please run ffmpegfs with --log_maxlevel=INFO to get the whole data. Probably even --log_maxlevel=TRACE would be good, although this may spoil the tests as it logs a whole lotta stuff. INFO should be sufficient, though.

nschlia commented 4 years ago

Revamped frame generation code