-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Same fuse-ts binaries on the same system accessing the same segments produce different uncut.ts #16
Comments
@MaZderMind If these mounts still exist, can you send me the contents of each As a next measure you could do a |
The mounts kind'of fixed themselfs shortly after me opening the issue but I have copies of them. The log is identical apart from the changes to the cut-times. I attached them. logs.zip As a temporary countermeasure we added |
I also theorized about the remove-rename scenario; will check |
Yes, this was always an issue, but it is resolved by the "EndPadding" mechanism. I mean, you mentioned different uncut.ts, not broken ones. If the last segment file that is found when creating the mount is growing later, there might be differences in the data delivered in uncut.ts - but this would always only happen alongside a change in advertised size of uncut.ts which is not happening in your case. I remember that there issues with the FD cache, it is possible that there is a kind of refcount mechanism and that the repair you have seen is correlated with the last open FD on uncut.ts to be closed, and then later reopened with a refreshed segment collection. But this also needs some external change to the segments to be a plausible explanation. |
We still have the Problem regularly, about every 5 fuse-ts invocations. It can be detected by parsing the .ts file with
Examining the broken and the good filed with xxd and a small python script shows, that, while the files have exactly the same length, their content differs (and the broken file indeed contains different content not just zeros):
What could we do to help identify the root cause? As I said I'm quite sure I can reproduce the Problem, maybe even kind-of automatic. The current process is something like Mount -> Cut in Shotcut (includes seeking through the file) -> broken in 1 out of 5 cases -> re-prepare -> good, so the Act of Seeking in the File with Shotcut might be one of the triggering factors. As the Problem can be triggered after the Event and we have the time to do experiments on this, we could absolutely try a debug build in order to check output, however it might produce a huge amount of unrelated output that I might need to filter. I could also attach a gdb session onto a broken fuse-ts process and start a fresh one in parallel, so we could examine them in-situ, however I might need some assistance with that. |
@MaZderMind If you could provide the "filelist" content as well as the "log" output, which should both be available as virtual files, it might be sufficient. |
Alright, I'll use the debug-build to cut the remaining Videos tomorrow and collect all the output and information that I can whenever I hit another broken file. |
@MaZderMind |
I have not seen the problem since 2022. I'd suggest to close this issue opportunistically and reopen it in case the same Issue ever happens again. I'll make sure to update the binary before the next T4AT. |
I have a very mysterious problem, whereby two identical fuse-ts binaries running on the same system accessing the same segments produce different uncut.ts files:
I ran shasum, hexdump, rsync and lots of different tools on the mount and kept getting consistent results. I also had 2 of 2 mounts from yesterday evening broken this way, that, upon re-invocation today are now fine.
The text was updated successfully, but these errors were encountered: