search

ribbons / RadioDownloader

An easy to use application for managing podcast subscriptions and downloads.
https://nerdoftheherd.com/tools/radiodld/
GNU General Public License v3.0
15 stars 11 forks source link

Size of database? (Corruption issue) #261

Closed Scurra01 closed 3 months ago

Scurra01 commented 3 months ago

I've had the 'corrupt database' issue a few times now, and I am wondering if it is because the store.db file appears to be over 1gb in size? And I am not sure how it has gotten that large?! I mean, I do have a massive archive now, but I am fine with that. I thought I had done a clean reset when the error first happened, but the store.db file seems to have grown very large again. (Also, the "Do not delete audio files" checkbox is greyed out on the Clean Up page. Is this connected in some way?)

ribbons commented 3 months ago

No, I wouldn't expect the size to be the reason for the corruption. As an aside, 1GB isn't the largest I've heard of, the reporter of #240 mentioned a 10GB(!) database which didn't corrupt (but was rather slow :smile:).

sqlite is the library that Radio Downloader uses to manage the database and it's got a good reputation for being pretty bullet-proof. Unfortunately in the case you're describing I'd guess it to be the usual corruption suspects - storage issues, memory issues etc. One other (more unusual) point that's worth me mentioning just in case is if the database is located on a network share of some kind this can cause problems, though I'd generally expect the default location to be located on the local machine itself.

Re: do not delete audio files being greyed out - this is expected behaviour if 'Have missing audio files' is checked (as it is by default) - un-checking that should enable it. The logic being that if only downloads with missing audio files are being cleaned up there aren't any audio files to leave behind.

Let me know if that covers everything or if you think you've found a reproducible bug with the application?

Scurra01 commented 3 months ago

Thanks. My files are on an NAS but the database is on my local drive. I just subscribed to a new feed, and now it's crashing routinely on open but not with the 'corrupt database' message; the error message doesn't stay on screen long enough for me to see what it is. I rolled back to a previous copy which seems to be fine, so it may be the particular feed that's the problem for me. I still don't understand why store.db is so huge though? Has the database got records of everything I have ever downloaded even though they are no longer in the main access list? If so, is there a way I can clear it?

(Thanks for the clarification about the "do not delete" option - I get it now, but it definitely wasn't clear to me what to do!)

Scurra01 commented 3 months ago

Ah. This time I tried just a download from the new feed, rather than adding a subscription, and the error persisted long enough for me to see it and send it on. And I get a link which says that the problem is probably solved in a new version (but the links on that page to Windows development builds don't work? The Linux link refers to what the error may be - it suggest that it may be an overly long file name, although I am not sure how that is possible - I have folders and files with much longer names than this one!

ribbons commented 3 months ago

And I get a link which says that the problem is probably solved in a new version (but the links on that page to Windows development builds don't work? The Linux link refers to what the error may be - it suggest that it may be an overly long file name, although I am not sure how that is possible - I have folders and files with much longer names than this one!

The build artefacts get cleaned up after a while, I've just re-triggered the build so the download links should work now. I think you may be misunderstanding what you're seeing under the Linux link, that's the commit message from the most recent commit which is fixing a bug related to very long path names.

Let me know if this fixes your issue (or an error report number if not).

Scurra01 commented 3 months ago

OK, thanks for doing that - I downloaded a new build from there, and now it isn't crashing when I add a new feed. Instead, it's just generating a "local problem" error, saying it can't find the path even though other podcasts seem to be downloading fine.

ribbons commented 3 months ago

Bit difficult to diagnose without the exact error message and some additional details, are you able to elaborate?

Scurra01 commented 3 months ago

The only error message I can see says Encountered an error saving the downloaded file. The system cannot find the path specified. You may need to select a new location for saving downloaded programmes or adjust the file name format under Options -> Main Options. Obviously I can't select a new location for downloads as that would mess everything else up. The program seems to be running fine otherwise - it's downloaded several podcasts this morning OK. But if I retry the new ones I added after the reinstall, I continue to get this message.

ribbons commented 3 months ago

If you are able to share the podcast URL and episode name that's having the issue, the configured download location and the download filename format template I can have a go at trying to reproduce the issue.

ribbons commented 3 months ago

No further details from user so unable to reproduce. Feel free to re-open, providing more details.