Tablo Ripper - Automatically download new recordings

Thanks! I don’t have access to a 32-big Windows machine (at home anyway), and this is for my stepson… I’ll let you know how it works.

Oops. When I try to run it, I now get the message “C:\Program Files\TabloRipper/TabloRipper is not a valid Win32 application”…

@Cutter
When does the message occur? Did it install correctly? Screen shot please.

Another thing to try, it’d entirely possible you don’t have the .NET runtime installed (that’s common with XP). You can get it here:

http://www.microsoft.com/en-us/download/details.aspx?id=17718

Just a trivial suggestion. When you stop the background operation in Tablo RIpper, it stops wherever it’s at I believe. I would think it might be better to finish up the current title and then stop. Reason is, if your output folder is MCEBuddy’s monitor folder, MCEBuddy seems to see when data flow stops on a file, it’s time to do it’s work on it. If you pause MCEBuddy before Tablo Ripper is stopped, you can start MCEBuddy again after you start background action in Tablo Ripper, but you need to know Tablo Ripper is actually pushing bits on the incomplete file again before you start MCEBuddy, or MCEBuddy will think the file is complete and start work again on that incomplete file.

That’s alot of words up there, so I hope you get what I’m saying.

Side note on MCEBuddy - There is an abundance of features and capabilities built into MCEBuddy. I have used this program for almost a year now, and I maybe only have used or tried 1/4 of the features. I am about 1/2 way through ripping my current Tablo HD and I am still experimenting as I see different things I’d like in the output. Increasing volume is one, breaking out subtitles another, creating series folders another – And there is much more to consider.

I am saying this so others might decide to do their experimenting before starting the real ripping chore. I have already restart from scratch once, and I almost feel I should do it again now that I have working subtitles available and taken out of the mp4 files from Tablo Ripper. Also, moving the volume to about 120% from the standard setting in MCEBuddy brings volume into a more reasonable range in comparison to most of my real movie titles from BR/DVD’s.

CycleCJ you are a very talented person to have put this ultra-useful program together.

-Rodger

1 Like

Thanks for the suggestions and kind words!

I 100% agree with your insight into MCEBuddy. I intentionally omitted any duplication of features in TabloRipper (like volume adjustments, different output formats, removing commercials, etc.) because MCEBuddy already does SO MUCH. Why reinvent the wheel?

And I opted for safety when cancelling a rip - I kill the FFMPEG thread. Why? Because if you immediately restart ripping the same video, you’ll collide with the original thread’s file name. If you know what’s going on, it’s easy to detect and correct. But if you don’t, then you’ll get very confused.

Thanks again for the help!

That idea would work fine, except users will need to be aware to stop MCEbuddy fully before stopping Tablo Ripper. If not, then there will be a partial title completed and put into the PLEX server and even though Tablo Ripper will start over on processing that particular title, MCEBuddy will not look at it again as it will see that title already completed in it’s database. So, in essence, 1 title will be lost, or at least not fully completed if a user is unaware of how MCEBuddy works.

Again, I know this and it really isn’t a big deal for me to take into account how to do this properly where no bad or lost tiles happen, but then again, I didn’t know it until after more then a couple of titles were mishandled in my process.

-Rodger

I suppose so, just pressing the envelope a bit maybe for some. Anyway, I am more then happy with what you’ve succeeding in doing for me!

-Rodger

1 Like

The problem is, if you are running MCEBuddy with multiple concurrent conversions and you have an open slots waiting for titles to finish Ripping (remuxing actually), once you kill the background process, MCEBuddy will fill that open slot with the partially ripped title. You know, I am a power user, might be no one else will even be using multiple concurrent conversions with MCEBuddy, then you idea is a fine one.

-Rodger

I’ll try it. You are right, it is a matter of how fast you can get rid of the partial file in MCEBuddy’s monitored folder. My computer will most likely do the delete fast enough, but there’s also a matter of the OS thinking the file is still in use and won’t delete it right away. I’m at the office, so I might not get a chance to do this until I get home though.

-Rodger

Just had a thought. What if you used a temp area for muxing and as files finish that process, move them to the output folder. Then you can simply delete the files in the temp folder when background processing is stopped. MCEBuddy would never see anything but fully muxed files that way.

-Rpdger

1 Like

@marjamar
You’re so right - that’s the standard solution to a common problem. Wish I’d thought of it first (you beat me to it).

Please pick up the latest (version 1.1.5) and give it a try. And remember to uncheck the MCEBuddy option for “monitor subdirectories” on the “monitor location” screen.

I don’t see that it is doing anything different. Still seeing the files start in the output folder before they are fully muxed. You would need to only have them transfer there after they have been muxed in a temp folder.

-Rodger

That is what I did. It was only like 10 minutes old or something when I downloaded it.

-Rodger

Maybe I messed up? It’s been known to happen. I’m going to bump the version number, build, and re-upload.

Edit: Version 1.1.6 is “there” now. Please pick it up. What you should see is a “tmp” folder created below your output folder, and the .MP4 will be created there, then moved to the output folder upon completion.

OK, I’ll try it.

-Rodger

Thanks CycleJ for fixing this little issue with my setup. Much appreciated.

-Rodger

1 Like

It occurs immediately upon trying to launch it. Here is a screen grab of the error plus the installation, which appeared to have run without anything unusual.

The screen he showed is XP for sure.

-Rodger

1 Like

@Cutter
The answer appears to be that if you’re running an old copy of XP, and can get .Net 4 installed, you might be able to run the 32-bit version of TabloRipper.

Please let everyone know if/when you’re successful.

Thanks. I’m working on it now. Will keep you posted.