Skip to content

Conversation

@arbusam
Copy link
Contributor

@arbusam arbusam commented Jul 15, 2025

Fixes #241 by adding a setting called trackVideoIDs that can track if a video has already been downloaded and not download it again, even if the file has been moved, renamed or deleted.

This works by adding a new value to attachments.json called muxed that is set to true once the video has been fully downloaded and muxed. If muxed is true the program will just treat that video as muxed, even if it can't find it.

However, if a video file is moved or renamed this won't be able to delete it after daysToKeepVideos.

arbusam added 2 commits July 15, 2025 14:13
…wnloaded previously and not download again, even if video had been moved, renamed or deleted.
@Inrixia
Copy link
Owner

Inrixia commented Jul 15, 2025

Haven't had the chance to review this yet. But instead of using a muxed flag just check muxedBytes !== undefined

@arbusam
Copy link
Contributor Author

arbusam commented Jul 15, 2025

Doesn't muxedBytes appear at the start of muxing, not at the end? If I do that instead of a flag I think that would mean that if the code is stopped during muxing it will assume that muxing was completed and leave it as a .partial.

@Inrixia
Copy link
Owner

Inrixia commented Jul 15, 2025

No muxedBytes is the final size after muxing.
And partialBytes is the size while/after downloading.

Ooh, actually yea muxedBytes does track the expected size while downloading I think. Good catch

@arbusam
Copy link
Contributor Author

arbusam commented Jul 15, 2025

Thanks, I think you might have been thinking of muxedBytes in getState() which does track the actual muxedBytes as defined here:

const muxedBytes = await Video.pathBytes(this.muxedPath);

@Inrixia
Copy link
Owner

Inrixia commented Jul 15, 2025

I think a better approach to this is instead to add a option to skip videos that have muxedBytes set but a missing file.

Since that scenario should only occur if a user has explicitly changed a file. And if someone wants to recover they can just disable it.

This simplifies things a lot as atm the current solution is a bit over complicated.

As for where this fix would go, probably at the top of the download method if I had to guess.

@Inrixia
Copy link
Owner

Inrixia commented Jul 15, 2025

Yea ima close this, could you implement what I mentioned above in a seperate pr? ❤️

@Inrixia Inrixia closed this Jul 15, 2025
@arbusam
Copy link
Contributor Author

arbusam commented Jul 15, 2025

Yeah I'll do that, but instead of the download method wouldn't it be simpler to put it in getState since all of the logic for checking bytes is already there?

@Inrixia
Copy link
Owner

Inrixia commented Jul 15, 2025

You could but since it's abnormal functionality triggered by a extra feature it'd make more sense to have it explicitly seperate at the top of the download method, which would allow for both logging that it's being skipped for that reason, and avoiding downloading subtitles, artwork etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants