[ClearToLand]

How would I determine this? I see nothing in the logs printed during the transfer...

*EVERYTHING* you need to know, and do, is in Post #12 above. READ, my young Padawan!

If you need personal hand-holding through this, I'm the wrong person for you. I'm a "Teach a person HOW to fish" :thumbsup:, not the "Give a person a FREE fish" :thumbsdown: type of fellow.

TLDR: PyTiVo Desktop is the *ONLY* TiVo-to-PC download program / method that bothers to even check for TS Sync Errors. No one else bothered or cares...

Do you want to work on this problem tonight? If so, I'll hang around a bit. If not, that's OK too...

 

[webminster]

This is a common problem. If the PS (Program Stream Protocol) download is too small, it's (i.e. the downloading software: kmttg, PyTiVo O.G., PyTiVo Desktop, etc...) only downloading the audio and you must use TS (Transport Stream Protocol) since your SOURCE must be H.264 (Go to Tuner Diagnostics on your TiVo Unit when tuned to the channel in question and you'll see) and PS won't download H.264. I talked about this problem a GREAT DEAL back in 2017 when @Dan203 was debating whether or not to add TS Sync Error Detection to PyTiVo Desktop (the majority here on TCF voted NO; I voted YES and SCREAMED the benefit of it wherever I could... Luckily, logic and common sense prevailed and @Dan203 included it - Thanks! :thumbsup: )
...

I have that version of PyTIVO Desktop... I set the options like that started. About 1/3 way said 161 packets, about 2/3 through updated to 277 affected packets. Started the retry cycle and looped through all 7 retries at decreasing speed, but did not complete successfully.

EDIT: Also tried installing it on a different machine, configured same. Same behavior, usually starts throwing 160 affected packets around 1/3 way in (500MB or so).

 

[Dan203]

I have that version of PyTIVO Desktop... I set the options like that started. About 1/3 way said 161 packets, about 2/3 through updated to 277 affected packets. Started the retry cycle and looped through all 7 retries at decreasing speed, but did not complete successfully.

EDIT: Also tried installing it on a different machine, configured same. Same behavior, usually starts throwing 160 affected packets around 1/3 way in (500MB or so).

The effected packets are almost always in the exact same place. Slowing the transfer down can help, but doesn't always work. It seems like some errors are just in the source file and will make it to the transfer no matter how slow you go.

 

[ClearToLand]

I have that version of PyTIVO Desktop... I set the options like that started. About 1/3 way said 161 packets, about 2/3 through updated to 277 affected packets. Started the retry cycle and looped through all 7 retries at decreasing speed, but did not complete successfully.

Well, sorry to break the news to you but, that file / show has 'problems'.

Once you get it 'low enuf', VideoReDo might be able to access it and DELETE the bad segments (i.e. Many folks believe that VideoReDo 'fixes' these problems - it doesn't. What it DOES do is 'attempt' to re-sync the stream from the 'problem' point onward. Whatever it can't understand, it has to DELETE. VideoReDo uses DirectShow Mode 2, which is the BEST decoding method. kmttg can use DirectShow Mode 1 (if you partially install the old TiVo Desktop software and / or load the DLL manually - @Dan203 had posted instructions 'somewhere', IIRC), which, while almost as good, is nonetheless *FREE* ).

TiVoLibre, while also FREE, is way down in third place since it drops a LOT of data before it's able to re-sync.

TiVoDecode, in case you were wondering, was never fully developed for decoding TS streams. It works fine with PS streams, AFAICT, but 'some folks' forget to mention this important differentiation and still 'blindly' recommend it.

I'm OCD so I try to get my TS Sync Errors down into the single digits before I let kmttg "QSfix" have a try at them. What a few of us 'diehards' do is let PyTiVo Desktop do the download to a .tivo file and then use kmttg to decrypt to a .ts file, extract the closed captions, metadata, etc...

You can move the pointer two more CLICKs towards Slow OR you can increase the number of retries OR you can just accept the fact and move on.

Tonight, I would like you to try another show - preferably one from an MPEG-2 channel (again, check Tuner Diagnostics) to see a SUCCESSFUL PyTiVo Desktop Transport Stream Protocol download so that you'll have something to base your future PyTiVo Desktop settings decisions on.

1. What is the initial transfer speed of your download starting at?
   Bolts have Gigabit Ethernet Ports (up to 1000 Mbps) and sometimes you'll have to drop all the way down to 16 Mbps or less to get a successful TS transfer with a 'problem' file / show.
   .
2. Did you check the channel of your 'problem' file / show in Tuner Diagnostics? Is it MPEG-2 or H.264?
   .
3. I was just about to give up on you since you didn't acknowledge my offer for over 15 minutes .
   Are you going to keep trying / working on this problem tonight?

 

[webminster]

Thanks for the replies. Seems like I'm going to need to keep my HDHomeRun Primes running in addition. Feels like I never used to have this much trouble - I haven't used it in a while, but used to download a lot of network stuff for my library.

Initial started maybe 70mb/s. Dropped down to 20mb/s before failing out. The channel shows as H.264 in diagnostics.
File it left behind in the download folder was same as with kmttg - black thumbnail, has seek errors and program lockup opening in VideoRedo.

This'll be probably last post of the day... been a long day. Thanks for advice so far.
-Alan

PS: By the way.. the show has "problems." Where do those problems originate, are you saying these are signal errors that don't show on TIVO playback? Recording or hardware issues?

 

[ClearToLand]

Thanks for the replies. Seems like I'm going to need to keep my HDHomeRun Primes running in addition. Feels like I never used to have this much trouble - I haven't used it in a while, but used to download a lot of network stuff for my library...

Maybe you never used Transport Stream Protocol on H.264 codec files before.

This'll be probably last post of the day... been a long day. Thanks for advice so far...

You're welcome.

PS: By the way.. the show has "problems." Where do those problems originate, are you saying these are signal errors that don't show on TIVO playback? Recording or hardware issues?

In here:

Figure 2 - Structure of the MPEG-2 Transport Stream packet

Wikipedia: MPEG Transport Stream

My 'opinion' is that the problems originate on the TiVo Unit HDD - either bad sectors or disk fragmentation that the TiVo OS can't properly handle quickly enough to properly form a Transport Stream Protocol Packet for transmission to our PCs. (That's why slowing things down allows the TiVo Unit to internally 'handle' some of the errors.)

@Dan203 works for VideoReDo and does this for a living, so I'll defer any 'deeper' explanation to him...

 

[ClearToLand]

I have that version of PyTIVO Desktop... I set the options like that started. About 1/3 way said 161 packets, about 2/3 through updated to 277 affected packets. Started the retry cycle and looped through all 7 retries at decreasing speed, but did not complete successfully.

EDIT: Also tried installing it on a different machine, configured same. Same behavior, usually starts throwing 160 affected packets around 1/3 way in (500MB or so).

The effected packets are almost always in the exact same place. Slowing the transfer down can help, but doesn't always work. It seems like some errors are just in the source file and will make it to the transfer no matter how slow you go.

@Dan203 ,

Now that I've FINALLY moved on from my 2009 Vista 32-bit PC w/3GB RAM to my 2010 Windows 7 64-bit PC w/6GB RAM *AND* a new (originally bought ~2017) Samsung EVO 250TB SSD (with my Windows SWAP and TEMP files, my Chrome TEMP files, along with my kmttg 'cut' directory, on the SSD this 'ancient' PC FLIES!), I'm able to use PyTiVo Desktop as it was originally intended and I *LOVE* the "Automatic Speed Reduction" logic.

Some files are just 'corrupt' though. When they continuously fail under PyTiVo Desktop, I make one final attempt with my modified version of PyTiVo (from one of your 2017 versions) on my laptop with the QoS Rate Limit set to 2Mbps.

I'd love to add @mlippert 's YAML Error Report, along with my NPL togo.py mod from 2017/18 (I used this before your "Automatic Speed Reduction" logic to manually reduce the QoS Rate Limit on my Managed Switch for subsequent retries when I saw TS Sync Errors on my tablet while reclining on my couch watching TV ):

@webminster ,

I was thinking about my TS Sync Error 'buddies' from 2017 (@mlippert and @reneg ) and looked to see what @mlippert had posted lately. I found this:

(June 23, 2021 at 7:59PM EDT)
example report attempting to download a file from my TiVo which never got a clean copy​

%YAML 1.2
---
fileName            : "Kim Possible Movie - So the Drama (2005) (Apr_26_2021, DISNEYHD-E).tivo"
fileSize            : 2898013680
tivoName            : LivingRoomRoamio (192.168.111.81)
downloadStarted     : 2021-05-01T17:00:26Z
attemptSaved        : 1
totalErrorPackets   : 103
downloadAttempts:
    - attemptNumber : 1
      status        : sync_errors_saved
      transfer      : { bytes:  2898013680, seconds: 3593.1, rate: "  6.15 Mb/s" }
      errorPackets:
          - { count:      2, start:  1616154480, end:  1616154856, startMB:  1541.29 }
          - { count:     51, start:  2018055992, end:  2018065580, startMB:  1924.57 }
          - { count:     50, start:  2418273212, end:  2418282612, startMB:  2306.25 }
    - attemptNumber : 2
      status        : sync_errors_aborted
      transfer      : { bytes:  2014306896, seconds:  517.7, rate: " 29.69 Mb/s" }
      errorPackets:
          - { count:     53, start:  1215169092, end:  1215179056, startMB:  1158.88 }
          - { count:     46, start:  1215179244, end:  1215187892, startMB:  1158.89 }
          - { count:     51, start:  2018055992, end:  2018065580, startMB:  1924.57 }
    - attemptNumber : 3
      status        : sync_errors_aborted
      transfer      : { bytes:  2417373632, seconds:  677.1, rate: " 27.24 Mb/s" }
      errorPackets:
          - { count:     53, start:  1215169092, end:  1215179056, startMB:  1158.88 }
          - { count:     46, start:  1215179244, end:  1215187892, startMB:  1158.89 }
          - { count:     50, start:  2418273212, end:  2418282612, startMB:  2306.25 }
    - attemptNumber : 4
      status        : sync_errors_aborted
      transfer      : { bytes:   802485968, seconds:  203.1, rate: " 30.15 Mb/s" }
      errorPackets:
          - { count:     65, start:   803791816, end:   803804036, startMB:   766.56 }
          - { count:     81, start:   803804224, end:   803819452, startMB:   766.57 }
...

A *BEAUTIFUL* effort of creating an 'easy-to-read / self-explanatory' TS Sync Error Report from an early version of PyTiVo Desktop that @mlippert painstakingly MANUALLY converted from Python 2.7x to Python 3.x :thumbsup: (which sadly has been quite ignored by the TiVo Community ).

 

[webminster]

Been a long couple of days, but have experimented some since and found that I can't succeed much if at all with the downloads via PyTIVo. I've checked several different shows and episodes thereof, and they pretty much all fail to download due to TS errors. I've set the download speed slider all the way to the left, and upped the retry count to 20. That makes PyTIVO start at about 30 mb/s. In the end, the speed drops to about 7-8 mb/s.

Checked the tuner diagnostics and all these are listed as H.264. Which makes some sense as an Xfinity subscriber, after their stupid "enhanced HD" changes a few years ago (e.g., switch to MPEG4 and downrezzing to 720p).