If you post specific details in the MG3 thread of the pyTiVo forum (link in signature) I will attempt to resolve your issue. Or start a new thread in this forum. (Don't want to clutter this thread with off-topic talk.)I have tried MG over several months with zero success . Usually comes up with no returns.
If there is a general (algorithmic or functional) way to handle such substitutions in code, I would like to know of it. Otherwise you have to handle each such case individually, e.g., substitute 'o' for 'ō'. And there appear to be hundreds of such possibilities if you look at the unicode tables, so the only practical way to do it is for users to call attention to specific cases and suggest the desired substitute character. I have no problem doing that in MG3.Yes, when accessing my pyTivo shares from my TiVo, I select the file named "Hannibal-S02E11-Kō No Mono.mpg" and pyTivo does nothing. It doesn't open the next screen where I would select the episode to be transferred.
As I mentioned in my post, Easier to use pyTivo , I believe @moyekj has kmttg replace "odd" characters in the kmttg download process to prevent this from happening.
The problem arises when users rename their files to match the TVDB name or any other name with characters not accepted by pyTivo/TiVo.
I use MG3 to rename all my shows to match the TVDB name and so I found the issue.
Perhaps the best place to address this, in my particular workflow, is with MG3 and have it replace the offending characters, but what if other users are using different applications to rename files and have a similar problem?
Should the change be made to MG3 or to pyTivo?
@dlfl & @Dan203 - Thoughts?
Dan,.......... There is a conversion routine that can convert some, but not all, unicode characters to a format it does support but on this particular file that conversion is failing.
My unaccenting solution for MG3 was done in C#. However I was curious about how to do it in Python and found there is at least one way to do it using unidecode.unidecode. This requires installing the unidecode package and importing unidecode in the code. I'm not sure what complications this may involve for your desktop distribution. Also, for this to solve the ffmpeg issue, you would have to construct the unaccented file name, temporarily rename the video file to the unaccented version, and pass that file name to ffmpeg via popen. Then rename the file to the original (accented) version after ffmpeg terminates.I was wrong about my original diagnosis. It wasn't ffmpeg, it was the way pyTivo calls ffmpeg. The function subprocess.Popen has an issue on Windows that it only supports a character set called cp1252, which seems to be a superset of ascii, but not full unicode. So it supports some, but not all, unicode characters.
Does your normal logon account have admin privileges? I suspect most forum readers run that way. If you don't, that might explain the need for "run as administrator"..........
UPDATE2: Uninstalled...again...and then used "Run as administrator" on the Windows installer. Seems to have done the trick. Not a difficult thing to do at all, of course, but would've saved a lot of time & trouble if the download website had simply suggested that.
I author two programs (links in signature) that can automate, or semi-automate, renaming video files based on metadata and placing them in folders created and named based on metadata.kmttg is abandoned in the sense that it won't be updated going forward. This is mostly because there was no one able to provide the "key" needed for much of kmttg's awesome functionality. Therefore that functionality won't work when the current key in use expires.
However, all the rest of kmttg's functionality will continue to work, in particular you should still be able to download and run the downloaded file through the same processing chain. One thing that won't work there is if you depend on naming the downloaded file with certain data such as the series number or episode number.
If you're using VRD to decrypt the downloaded file, kmttg will have VRD do the decryption and QSF in the same step, no extra file space needed. If you're running out of space it isn't the QSF step causing the problem it is probably the decryption.
MG3 uses mind/rpc only to search for seriesId's and programId's so yes, those two items will no longer be available. But all the other metadata is obtained from other sources which don't depend on the certificate.Doesn't Metagenerator 3 use mind/rpc? So won't it have the same issue with the certificate when it expires in December?
Just to be clear, MG3 doesn't do any TiVo uploads or downloads itself. It creates <video_file_name>.txt files that pyTiVo can use to send metadata along with video files uploaded from PC to TiVo (to the degree that operation is still possible). I think you know this but other thread readers may not.So after the certificate expires you'll no longer be able to use MG3 for pyTivo uploads because it wont be able to match the data from the TVDB to the requires TiVo series and program IDs right?
@moyekj ,the author of KMTTG, has been the source of certificates for MG3 and AFAIK he has given up on getting a new certificate. See the following post in the KMTTG thread and the next 5 or 6 posts after it:Yeah that's basically what I meant. After the expiration it wont be able to get the uploaded recordings to group with their recorded counterparts. That sucks. Was always a nice feature of MG3.
Does anyone know when the TiVo app itself will be updated with the new certificate? Maybe we can convince a hacker on reddit to grab the certificate, or do a little collection to pay someone to do it. (assuming it's not actually impossible now)