Closed petenun closed 1 year ago
Just as disclaimer, the --insecure
has no influence after the Download was added successfully.
I only need the curl
library for the api request due to some issue i don't quite understand ( something with how the TLS encryption gets established).
For the issue itself, i did not hear about this exact one, i had issues with the download in the past but there was both the audio and video missing.
To combat this and improve the performance i added the Hybrid Mode
, this allow me to handle the actual download while the ffmpeg
does it thing with the video file afterwards.
what's the actually issue is only visible within the log file, This can be obtained with a right click on the download and then you can choose to save it as text file or copy the text directly to the clipboard.
Hello, my problem is something similar. I sometimes have 5 second jumps in the videos. The video then jumps from 12:55 to 13:00. However, audio and video are skipped entirely. For a moment I then have a still image with image errors during this time. I'm using the default settings at 1080p.
However, audio and video are skipped entirely
The exact details are only avalible inside the ffmpeg log but this would make sense if one of the hundreds smaller segments the video is made of fails to get downloaded.
without the log i can not even know if you already use the Hybrid Mode
which has a much higher timeout and it can retry some failed segments.
I'm still trying to find time to get you some logs. In the meantime, is there a recommended mode? My config is set to "Default - ffmpeg", but would it better to have it set to "Hybrid Mode" or "Hybrid Mode - keep cache"? What are the main differences between the choices?
Hybrid Mode
is the best in my opinion, it is much faster than the Default - ffmpeg
since the download runs in parallel and i can catch a failed segment an i do one retry.
without getting to technical, the Hybrid Mode
downloads the video from CR 1:1 and then ffmpeg gets to work at the local maschine this cache copy of the video stream is what Hybrid Mode - keep cache
just does not delete after ffmpeg is done.
The downside is that you need more the space during the download (if you don't keep the cache) and SSDs have a finite amout of data you can write on, which usually high enough.
Wow - Hybrid mode is a LOT faster. In my initial test, everything downloaded quickly and file sizes are looking good. I'll keep an eye on it and will send logs if there are any failures.
I also discovered that I had an older copy of ffmpeg.exe in c:\windows, which is on the system path. Even though CRDL comes with a much more recent version, it might be possible that the ffmpeg.exe from the system path could have been used by Windows instead of the version in the CRDL directory now that CRDL is no longer located in the "Program Files" directory. Unfortunately I fixed the problem with the older version before running my last test so I'm not sure if that could have been a factor with the previous failures.
I also discovered that I had an older copy of ffmpeg.exe in c:\windows, which is on the system path. Even though CRDL comes with a much more recent version, it might be possible that the ffmpeg.exe from the system path could have been used by Windows instead of the version in the CRDL directory now that CRDL is no longer located in the "Program Files" directory. Unfortunately I fixed the problem with the older version before running my last test so I'm not sure if that could have been a factor with the previous failures.
You don't have to worry about that the downloader always takes the ffmpeg.exe
from the downloaders path.
I've have noticed similar varying file sizes sometimes when downloading since I started using it in August 22. It's noticably less in the last two months. Two examples:
I wrote a PowerShell Script that shows me files that do not match the average size of all other downloads by > 20% and I got quite a lot of results. But after watching many of them I couldn't find any problems. They have good audio, video and softsubs. Not a single error. I'm using default ffmpeg mode for everything. When trying to re-download them it yields the same result in ffmpeg and hybrid mode. There has to be a difference, but I haven't found it yet. Maybe these are 720p instead of 1080p.
I also checked my download of "By the grace of the gods" and "To your eternity" - sizes are good (but I used 1080p).
Not sure if I can help someone with that.
for v3.14 i downgraded ffmpeg again to 5.1 (without av1 support) i hope this helps with this issue.
@hama3254 tried GyanD or Btbn nightlies?
@tormento i wanted to use a new build (for AV1) and did not think it would change old stuff much but 2023-01-12-git-fc263f073e-full_build-www.gyan.dev
did make some issues in #664 with nvenc
and i don't know what else changed so back to ffmpeg 5.1 where i never heard of the video jumps and sync problem
.
@hama3254 but is ffmpeg used in hybrid mode too?
@tormento yes the hybrid mode only caches the data so ffmpeg can use it from local storage.
Hey @hama3254,
I'm running v3.13.1 and have gotten both single and batch downloads to "work" by relocating the program directory outside of \Program Files folder and by using the "--insecure" switch. However the resulting videos are, I can only describe as, full of "holes". In other words, the video stream will pause on the same frame for a long period of time while the audio keeps playing, then jumps ahead to catch-up, resulting in a lot of video jumps and subtitles that are out of sync. Videos are also only about half the size of a traditional video. Most 720p downloads are around 700mb, but lately they've been around 350mb in size at the same resolution using just the default "Copy" setting for ffmpeg . At first I thought CrunchyRoll just posted some buggy videos, but I'm seeing it all the time now for several different titles.
Have you seen or heard about anyone else encountering this same issue?
I've tried unchecking the "--insecure" switch. I then have to retry videos several times before they successfully download, but it doesn't seem to make any difference on the video size or skipping with or without "--insecure".
I've attached a screenshot of the file size difference. I haven't been able to figure out how to capture an attachment showing the video jumps and sync problem.
Here's another example. In this case 10 of the twelve files downloaded correctly but two did not which you can see from the highlighted file sizes. Repeated retrys on these files still produce the same results.
Did anyone manage to resolve this? It's happening a lot to me. Many episodes are downloaded at half the size (800mb) even in 1080p, which is normally 1.3-1.4gb.
Hey @hama3254,
I'm running v3.13.1 and have gotten both single and batch downloads to "work" by relocating the program directory outside of \Program Files folder and by using the "--insecure" switch. However the resulting videos are, I can only describe as, full of "holes". In other words, the video stream will pause on the same frame for a long period of time while the audio keeps playing, then jumps ahead to catch-up, resulting in a lot of video jumps and subtitles that are out of sync. Videos are also only about half the size of a traditional video. Most 720p downloads are around 700mb, but lately they've been around 350mb in size at the same resolution using just the default "Copy" setting for ffmpeg . At first I thought CrunchyRoll just posted some buggy videos, but I'm seeing it all the time now for several different titles.
Have you seen or heard about anyone else encountering this same issue?
I've tried unchecking the "--insecure" switch. I then have to retry videos several times before they successfully download, but it doesn't seem to make any difference on the video size or skipping with or without "--insecure".
I've attached a screenshot of the file size difference. I haven't been able to figure out how to capture an attachment showing the video jumps and sync problem.
Here's another example. In this case 10 of the twelve files downloaded correctly but two did not which you can see from the highlighted file sizes. Repeated retrys on these files still produce the same results.