1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

New program for 1 step TTG downloads, decryption, encoding - kmttg

Discussion in 'TiVo Home Media Features & TiVoToGo' started by moyekj, Mar 15, 2008.

  1. Feb 28, 2013 #4901 of 10413
    wmcbrine

    wmcbrine Ziphead

    10,369
    22
    Aug 2, 2003
    ...and Mac. Theoretically there's a Mac version. It sucks even more than TD for Windows, but it's there.
     
  2. Feb 28, 2013 #4902 of 10413
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    <sigh> The proper fix requires replacing less than 10 bytes in the tivoapp code, and they could (should) have had this in place and out the door in a matter of a day, with every TTG capable Tivo on the planet getting an update within a week. Instead they are going to make users upgrade their software in an attempt to implement a kludge.

    This is really pathetic. 'Most gripes that come across on these conferences blame TiVo for things of which they are not really culpable or responsible, but this is just a botched job on TiVo's part all the way around.
     
  3. Feb 28, 2013 #4903 of 10413
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Kinda like this bug, actually.
     
  4. Feb 28, 2013 #4904 of 10413
    Fofer

    Fofer XenForo Rocks! TCF Club

    82,152
    311
    Oct 29, 2000
    Sheesh. It's no wonder why the HD UI remains incomplete. My hunch is that all the actual programmers and engineers have left the TiVo building. Maybe a few interns are peeking at the code and trying their best?
     
  5. Feb 28, 2013 #4905 of 10413
    lpwcomp

    lpwcomp Active Member

    8,081
    2
    May 6, 2002
    John's...
    I didn't realize you were so intimately familiar with TiVo's s/w change and deployment process.

    Should they do this? Yes. Will they do this? No. From their point of view, changing TD addresses the issue and "fixes" the problem for most users. It wouldn't fix it for me if I was still using TD but like most other s/w providers, they don't care about people using unsupported OS's like Win2K nor do they care about third party apps. They might care about the ReadyNAS, but I suspect that even there that they will tell Netgear to change things on their end.
     
  6. Feb 28, 2013 #4906 of 10413
    Fofer

    Fofer XenForo Rocks! TCF Club

    82,152
    311
    Oct 29, 2000
    I'm pretty familiar with it from an end-user perspective, having had (and supported) many TiVo boxes installed in many homes over the course of a decade.

    Their s/w change and deployment process sucks.
     
  7. Feb 28, 2013 #4907 of 10413
    lpwcomp

    lpwcomp Active Member

    8,081
    2
    May 6, 2002
    John's...
    Not really. It just displays whatever is in the episodeNumber field, which mayt or may not be of the form ssee.

    If you add the correct programId to the metadata, you can sometimes get season and episode to display in the HDUI.
     
  8. Feb 28, 2013 #4908 of 10413
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    You mean their internal process, which is to say policy? If internal policies get in the way of proper support, they need to be dumped.

    If you mean the pysical deployment mechanism, then yes, I am very familir with it. It's pretty trivial.

    If you mean the code requirements, then I am completely familiar with it. I'm considering making the changes to my versions of tivoapp, and not waiting for Tivo. If they follow their published intent, then I almost surely will.

    No, it doesn't, from anyone's point of view. They have to publish a new version of TDT, which is every bit as difficult and resource consuming as publishing a new version of tivoapp, plus they then have to manually try to get everyone who has an old version of TDT to upgrade, and support all the users who have issues with the transition, perhaps for years to come.

    This looks very much like a prime example of what happens when a company allows marketing types to override the good sense of the engineers.

    From their perspectrive, that is not really the point. Again, from their perspective, they can invest a trivial amount of resources to completely fix the issue with no further repercussions regardless of the user or his platform, or they can create a neverending support issue for themselves.

    They might do all sorts of things. That does not make any of them wise or fiscally prudent.
     
  9. Feb 28, 2013 #4909 of 10413
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    In the past they have responded very effectively and quickly to squash bugs. Deployment of new features is not the issue, here.
     
  10. Feb 28, 2013 #4910 of 10413
    unitron

    unitron Active Member

    16,389
    2
    Apr 28, 2006
    semi-coastal NC
    I'd just like to see an honest explanation from them for why they coded in this time bomb in the first place.
     
  11. Feb 28, 2013 #4911 of 10413
    lpwcomp

    lpwcomp Active Member

    8,081
    2
    May 6, 2002
    John's...
    I take it then that you either used to work for TiVo in s/w development or have actually spoken or corresponded with someone who does/did. You know for a fact that it is "trivial" to deploy a fix to a single module to every Series2, 3 & 4 platform? Do you know for sure that the mechanisms are even still in place to deploy fixes to Series2 or 3 boxes? Not to mention the fact that if TiVo were actually performing unit, regression, and acceptance testing, even a trivial change would be more complex than you are implying.

    And what makes this particular approach the "right" one rather than merely the easiest. Simply modifying the expiration date of the cookie is just as much of a kludge as modifying TD.

    Once again, you know this how?

    No, this looks more like something that was partially but never fully implemented - verifying a transfer request. And the fact that this code was in there got lost in the cracks.

    How? Which part of THEY DON'T CARE ABOUT THIRD PARTY APPS! do you not understand?

    How exactly is this going to adversely affect their bottom line?
     
  12. Feb 28, 2013 #4912 of 10413
    lpwcomp

    lpwcomp Active Member

    8,081
    2
    May 6, 2002
    John's...
    Tell that to the Series1 owners stil waiting for a fix to the DST problem.
     
  13. Feb 28, 2013 #4913 of 10413
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    They did fix that for most users, and quickly. My Sister's S1 DirecTiVo always has the correct time. So did my Philips SA TiVo, until it died.
     
  14. Feb 28, 2013 #4914 of 10413
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    No.

    Yes. It hasn't changed since the Series I, by the way.

    Yes. For that matter, one of my S3 Tivos just got a software update last night. It upgraded from 9.02 to 11.0k. Obviously the update mechanism remains in place for the S3. I can't speak from actual experience on the S2, since I have never owned an S2, but there would be little point in removing it.

    Not really. Our lab performs regression and acceptance testing on every piece of hardware we deploy, and most of the hardware we use is vastly more complex than a TiVo. We also deploy one whole helluva lot more than 20 or so different models of equipment. A typical cycle for simpler devices such as a TDM mux is six weeks, but in an emergency we have regression tested software updates on massive core routers in less than 3 days.

    No, it isn't. Admittedly it is a bit of a shoehorn approach, but it is nothing like the level of kludge modifying TD is. One is a matter of patching something that is broken with a bit of bailing wire and some duct tape, while the other is breaking a second item to make up for the fact the first one is broken. The patch completely eliminates the issue for all deployments current and future, while the other requires maintaining a permanent sticky note reminding everyone of the pothole that was never patched.

    Are you kidding me? How do I know that their releasing a new version of TDT requires every user of TDT to upgrade to the new version in order to take advantage of the fix? Are you seriously asking me how I know that everyone has to download and install the new software?

    You mistake my meaning. I am talking about TiVo's public response to the current issue, not how the time bomb got into the code 'way back when.

    What part of "I'm not talking about 3rd party apps" do you not understand? It is true fixing the code in tivoapp alleviates the issue for 3rd party apps, but that is just an unintended parallel benefit. It alleviates the issue for all versions of TDT and all users of TDT, or any other supported app, now and in the future.

    You don't think that hundreds of additional calls to the TiVo help desk isn't a drain on their resources? You don't think that implementing the training for the help desk personel to handle the issue is not a drain on their resoureces? You don't think that keeping the help staff informed of the issue for an indefinite amount of time into the future is a drain on their resources?
     
  15. Feb 28, 2013 #4915 of 10413
    windracer

    windracer joined the 10k club

    11,580
    3
    Jan 3, 2003
    St. Pete, FL
    Actually, it was that easy. When I was testing I had copied the wrong .jar file that I thought contained my change. :eek: After adding that single line, I was able to get Galleon ToGo downloads working again. :up:
     
  16. Mar 1, 2013 #4916 of 10413
    lpwcomp

    lpwcomp Active Member

    8,081
    2
    May 6, 2002
    John's...
    lhorer,

    You are making assumptions about what is necessary deploy a fix to every single platform when you you have absolutely no knowledge of what is actually involved. You have no idea if it is even possible to deploy a single module rather than modifying every platform's current s/w release. And if they can't, even if they manage to get every current s/w release modified, actually getting every non-Series1 SA TiVo updated would be a nightmare. They currently have to roll-out new releases over a period of several weeks by controlling which TSNs can access it until it is fully deployed. Can you imagine having to schedule it for all of the affected TiVos, as opposed to putting out a new TD that is very far from being in ubiquitous use. It's also one d/l for each user of TD as opposed to a d/l for every TiVo, whether TD is being used or not.

    It is flat out delusional to think that *fixing* TD as opposed to *fixing* tivoapp will result in a c/s problem "for years to come". Once they have a modified TD in place, they'll probably send out email and/or a TiVo message. Whether you want to believe it or not, this is actually the fastest way to get TD working again for those who don't know how to "fix" it themselves.

    As to my "Once again, you know this how?", I was referring to your statement saying that changing and deploying TD was "every bit as difficult and resource consuming as" changing and deploying tivoapp. The truth is, you have absolutely no idea what either option entails.
     
  17. Mar 1, 2013 #4917 of 10413
    sanjonny

    sanjonny New Member

    202
    0
    Nov 2, 2008
    Not that I don't want to jump on the bash tivo (I tend to bash them directly, every month thru their surveys and random naggy emails) but I have a few kmttg related questions and comments.

    As many of you know, I have not written nor really thought about code in years and most of you especially lhorer and mcbrine and especially moyekj would just laugh at how lost and silly my sparce coding is, but I have been doing some very useful things that I think might benefit all tivo/video processors and I imagine that many of you already do this kind of stuff but don't share it with the world, or maybe aren't as lazy as I am in wanting to automate some stuff but have it turn out the way I want it, so I am kinda forcing myself to learn some old stuff like nesting variables in bat files and all kinds of stuff I gave up long ago, so I guess I am spending 10 hours to save 5 minutes ultimately, but hopefully it will be 5 minutes over and over again.

    Anyway, enough of my struggles. At some point I hope to post what I am doing and have actual qualified people refine and improve it should they be interested

    BUT, First my suggestion. Isn't it time to close this thread and start kmttg 2, the new thread that can redirect to this 165 pager or whatever thread. Just a thought.

    Second, mostly for moyekj, but anyone else can also help, I am trying to get the output of handbrakecli when encoding stuff so I can compare some stuff thru an automated process. Because I am trying to kinda bolt on what I am doing to kmttg, its nice if I can get it to work in kmttg unless it is just impossible to do. I already checked and its not a version issue and I think its not a output issue as I am seeking the sterror log and not the stout log that I imagine is how kmttg gives us progress but I tried

    Code:
    Big long handbrakecli code with the ending :vbv-maxrate=10000:vbv-bufsize=10000 -v -o OUTPUT
    is my customized encode command and works fine. When I am not using kmttg but a batch file I can add 2>(outputfilestringname).txt to get the error log which gives me a bunch of statistics that I am analysing.
    So I am guessing the command in the kmttg.enc should be
    Code:
    Big long handbrakecli code with the ending :vbv-maxrate=10000:vbv-bufsize=10000 -v -o OUTPUT 2> OUTPUT.txt
    Which at least in the commandline shown on kmttg when it actually runs the command shows the correct filename(output).txt and correctly processes the video but when it runs it doesn't generate the txt(log) file anywhere. I searched just in case it put it somewhere else.

    So if the filename was say PATH\community - new episode.mpg

    the kmttg bottom window shows the correct
    Code:
    Big long handbrakecli code with the ending :vbv-maxrate=10000:vbv-bufsize=10000 -v -o "PATH\community - new episode.mkv" 2> "PATH\community - new episode.txt"
    but the log file is not generated.

    Is this because of inner background stuff I am not able to see, or is something else going on, or basically am I doing something wrong?

    Thanks in advance for your help!
     
  18. Mar 1, 2013 #4918 of 10413
    moyekj

    moyekj Well-Known Member

    11,150
    33
    Jan 23, 2006
    Mission...
    If you want to see stdout/stderr while any kmttg job is running double-click on the job in the job table if using the kmttg GUI. The command line stdout/stderr redirect ">" and "2>" only work within context of a cmd shell so have no meaning when launching via kmttg.
     
  19. Mar 1, 2013 #4919 of 10413
    orinaccio

    orinaccio New Member

    43
    0
    Sep 18, 2003
    Los Angeles
    I did a search on this thread for "sleep" but unable to find anything addressing this, so I apologize if this was already addressed.

    I recently upgraded to Mountain Lion OS X and have noticed that initially working fine, my transfers are "hanging" at some point during the transfer, meaning that zero bytes are being transmitted. There seems to be no time out error but the "time remaining" continues to grow higher and higher as zero bytes are transmitted. I left it running overnight and by morning i found that there was still zero bytes being transmitted (after 900 megs of data of transferred data), with no time out or error.

    Suspecting that the computer going to sleep might have something to do with it, I kept the computer from going to sleep, and lo and behold the transfer completed fine.

    Is there a known issue with Mountain Lion, its energy saver settings (e.g. Sleep), and KMTTG?

    Thanks for the wonderful program by the way. I've been using it for years and am grateful to the developer and contributors for what it does.
     
  20. Mar 1, 2013 #4920 of 10413
    CuriousMark

    CuriousMark Forum Denizen

    2,606
    0
    Jan 13, 2005
    SoCal
    I am enjoying the debate between the two of you (lpwcomp and lrhorer) and find it very enlightening. I thought I would throw a new thought into the mix and ask you what you both think about it.

    One issue TiVo will need to consider when they decide whether to fix Tivoapp is a comparison of how many old S2 and S3 boxes that a software update will break by doing the partition swap versus the number of TiVo Transfer users it will help. Of course this decomposes into some detail questions. Things like will they need to do a full partition swap update to fix Tivoapp? How many boxes does an update break, especially older boxes? How many people is the problem affecting so that these numbers can be compared? What is the support cost for doing an update that can break boxes (or surface a failure that is still hidden) versus the never ending but always declining cost of support for a declining cohort of users with older TiVo boxes.

    I would expect that this is the kind of calculus TiVo does for these kinds of errors.
     

Share This Page