You can reset the app by deleting the C:\Users\<username>\AppData\Roaming\tablo-tools directory (none of it’s important at this point). Give that a shot and see where we’re at.
I’m working on something else to more generally help with troubleshooting that I hope to have ready soon … or I’ll do an alpha.2 … or both.
Don’t bother, I got confirmation it didn’t work 
I installed tablo-tools_0.1.5-alpha.1_amd64.deb and basic function seems to work. I haven’t really gone through much, but it “works”. I always delete the configuration directory between upgrades.
Looks beautiful!
I am still seeing the following issue. If you immediately search and export a second recording it re-downloads the first recording in the location where the first recording was placed. This problem exists in v0.1.4 (tested in Linux) and v0.1.5-alpha (tested in WIndows 10). Follow these steps to reproduce:
Did you see that it existed from here or the in-app status indicator I added?
That one definitely didn’t have anything interesting in for most - I need to make what they do/are for more clear in the future. Especially if/when there end up being (enough) settings that you don’t want to lose and thus wouldn’t want to wipe the whole directory.
Thanks for looking through stuff!
The fully deleting and reinstalling the alpha version worked. After an hour of “Finding” the json files, I seem to have (I’m guesstimating based on various things) all the “airing” files but no “show” ones have been generated (yet), now just “spinning”. Finding recordings has been on 99% throughout.
I’m going to leave it running, but have to turn to other things. More probably tomorrow. (Incidentally APLTablo manages to work through all the 6,000/12,000 files in maybe 3 minutes and can then access and download (or play) all the programs that are actually on the hard drive, so it is handling the database somehow.
The interface is very attractive and I’m grateful to you for putting this together.
I had been doing that (deleting config) since the previous install wasn’t working right. Wanted to get a “fresh start” with each new version. If there were some remnant which may have been from the issue… could contaminate any future releases.
~/.config/tablo-tools/logs/main.log is spammed with
[2020-04-13 18:36:07.802] [info] Checking for update
[2020-04-13 18:36:07.811] [error] Error: Error: ENOENT: no such file or directory, open '/opt/TabloTools/resources/app-update.yml'
I know this is an alpha release, I’m finding this in the terminal
[Error: ENOENT: no such file or directory, open '/opt/TabloTools/resources/app-update.yml'] {
errno: -2,
code: 'ENOENT',
syscall: 'open',
path: '/opt/TabloTools/resources/app-update.yml'
}
(node:36205) UnhandledPromiseRejectionWarning: Error: Missing required channel argument
at WebContents.send (electron/js2c/browser_init.js:3612:11)
at d.<anonymous> (/opt/TabloTools/resources/app.asar/webpack:/app/main.prod.js:388:22)
at d.emit (events.js:215:7)
at /opt/TabloTools/resources/app.asar/webpack:/app/main.prod.js:6607:12
(node:36205) UnhandledPromiseRejectionWarning: Error: Missing required channel argument
at WebContents.send (electron/js2c/browser_init.js:3612:11)
at d.<anonymous> (/opt/TabloTools/resources/app.asar/webpack:/app/main.prod.js:388:22)
at d.emit (events.js:215:7)
at /opt/TabloTools/resources/app.asar/webpack:/app/main.prod.js:6607:12
(node:36205) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:36205) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:36205) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:36205) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Not sure if that helps any, from the Devtools console, I get this just browsing the shows - that’s about as far as I’ve gotten, just clicking though. But all my / are in the proper direction 
DevTools failed to parse SourceMap: file:///opt/TabloTools/resources/app.asar/dist/renderer.prod.js.map
DevTools failed to parse SourceMap: file:///opt/TabloTools/resources/app.asar/dist/style.css.map
Hi — Awesome job on this – just downloaded, quick install, intuitive, worked right away. Super-like!
Cheers!
Those are all generally unimportant - I’ll try to shut them up.
Happy to say it’s now mostly working. Took 60 minutes to make a first pass through the database of 13,000 items, then another 45 minutes to work through the results and finish up with the 6,000 odd recordings actually on the drive.
But interestingly there are two copies showing of every episode I have checked out so far on the search page. Don’t know if that’s something that will replicate every time (maybe something to do with the size of the database or being on firmware 2.20 or simply somehow something I did) - but of course I don’t want to purge and go back to the nearly two hour process. Both copies play correctly. If I delete either “copy” the recording deletes from the Tablo and the other “copy” cannot of course be played but needs to be deleted to vanish from the Tablo Tools list/search. (These are recent programs so nothing to do with being phantom recordings.)
I am finding that after almost every action like playing, deleting or exporting the page becomes unresponsive (can’t click on anything), but if I close Tablo Tools and reopen it, then it works until the next such action again freezes things. That is, I realize, going to be almost impossible to “fix” - could be all sorts of causes including in principle tied to my computer (but doesn’t happen with other programs, Tablo related or not).
Haven’t seen what happens with new recordings yet, but will tomorrow.
Thanks for this. Very nice. One hour recording (3 Mbps/720) exported in 4 minutes flat.
Let’s call that your computer?!? I have recordings set to 5Mbps, if it were an actual HD recording it’s within a couple minutes, and my PC is old. (I’ve already deleted my logs)
I know tablo-tools is useing the same ffmpeg virtually anyone else uses, so they’re comparable. Unless there’s some settings to make it “special”, I admittingly don’t understand ffmpeg’s documentation.
I’m working on this, it’s just taking longer than I expected…
Well, that’s kind of progress. You’ll probably want to go into Settings and turn off Auto rebuild (30 minutes) if you haven’t already. I added it to the list to make that more configurable.
As much as I’d like to believe that was actually the 1hr recording, did you check it? Or had you exported something just before it, b/c it sounds like this that I’m working on. Plus the time sounds more like a 30min recording.
Still more later on try to speed up your scenario.
I’m seeing the same issue as bbaorbb - after first export newer ones fail but it appears to me in monitoring the export that it exports the later file up to the length of the first one (in a proper directory) and then when the length of the first one is finished instantly corrupts the later download. Specifically, in a download queue, make first download an hour long then download a long program (in my case a one hour TV program followed by a bunch of movies); I can see the subsequent movies downloading in their dedicated subdirectories and even get the appropriate movie screenshot icon on the file but when the one hour period is concluded the file suddenly loses its screenshot icon, stops downloading and is not playable; the main download tracker suddenly “completes” even though it was only about 40% through and indicates success.
My previous freezing might be down to the auto-rebuild of the database; we’ll see if that’s gone now that I’ve turned that off per your suggestion (though of course makes it hard to keep current with new recordings unless one doesn’t keep a large library on the hard drive).
Hope that helps.
The db won’t try to “double” build - I just envisioned you thinking you were going to do something real quick and it decides that’s the right time to start.
Good gravy, that is a serious load of recordings! Impressive!!
For clarification, I haven’t exported via tablo-tools, just noticed it packs ffmpeg same tool other 3rd apps he’s and I’ve used it directly, I suspect similar results
Well, just let me note I do have a “double” database with Tablo Tools right now - two of every valid recording listed in the search process (both play, etc.), and that hasn’t ever happened with TabloRipper or APLTablo. I don’t think the programs are double-counted in the summary data on the Home page, though, just in the output in Search.
More important on the first export being exported again though named and folder-placed for those in a list of export, that continues to happen. Sometimes the resulting additional file is unplayable (corrupt I guess) and sometimes it is indeed the first program exported (though labeled as the latter program), as others have reported.
No freezing with the database rebuild turned off (so far).
For an alpha this is very impressive and promising. Thank you!
A side thing I noticed while testing a manual recording yesterday, it looks like manual recordings are NOT displayed in the Browse | Shows tab.
The Tablo app shows the manual recording…
And Tablo Tools sees a total of 5 recordings which is correct…
But Browse shows only shows 4 recordings…
and is missing the manual recording.
I went to Browse | Search to see if I could see it there and it appears to be “stuck” reading the recordings…
as it never displays anything.
I deleted the manual recording in the Tablo app and went back into Tablo Tools and everything worked as expected.
I think it may not be able to identify a manual recording which is causing other issues.
