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 25, 2010 #1981 of 10413
    CrispyCritter

    CrispyCritter Purple Ribbon Wearer

    3,646
    1
    Feb 28, 2001
    North...
    Except that the user is going to have to treat those shows special in many cases already - the metadata is bad for those series.

    Don't you give up several advantages by going to recording-based id instead of episode-based id? I know it complicates what I'm currently doing tremendously, which is constructing archives of series from reruns. I'll end up with many copies of the same rerun unless I maintain a complete archive on the TiVo as well to avoid re-recording the same program. But not having the space to do that is why I started using kmttg in the first place!

    It also will mean folks with multiple TiVos will have to modify their auto-transfer info if they ever have a show recorded on more than one TiVo, as I often do. Otherwise they'll end up with multiple copies on the PC.

    People who use a more general matching criteria, like matching keyword "Christmas", will also start getting more than one copy of a show if it gets recorded more than once in a season (or even over multiple seasons!). And if you ever have plans of expanding to actor based matching, you'll encounter this even more!

    I realize people use kmttg for different purposes. I use it for archiving, and for that, the current episode-based id is perfect in most cases - I just need some mechanism to fall back on when the metadata is incorrect. I agree that the recording-based id is in some sense the most basic id - it will always be available and it solves most re-transmission problems. That's why I suggested it as the fall-back mechanism! But I view it as a step backwards for what I personally want from kmttg.

    In practice, the progamId for series is almost always some munging of seriesId and episodeNumber - my guess is that's the easiest thing to do for producers. Not a big deal, except in the cases where the rest of the info is inaccurate, or you want to do some checking of auto.history :) "Buffy" is an example where I could do something automatically if programId was included in the metadata, and I was just curious why it wasn't. (I think "Buffy" reports the season number instead of episode number for episodeNumber)
     
  2. Feb 25, 2010 #1982 of 10413
    moyekj

    moyekj Well-Known Member

    11,142
    31
    Jan 23, 2006
    Mission...
    OK I realize now what you are talking about. By putting timestamp as part of an id this will cause issues if you re-record same show again on a different date on any of your TiVos. So the combination of date filter and <ignorehistory> is not sufficient to solve the issue for you? Would it help to have a auto transfer entry specific date filter?
     
  3. Feb 25, 2010 #1983 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    Hi moyekj,
    I installed your beta with the mpg.qsfix to block files that were already qsf'd. Now that background Videoredo doesn't qsfix anything, and videoredo is stuck with "tivo file open error.. please check media access key. This doesn't happen from the GUI
     
  4. Feb 25, 2010 #1984 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    oh, when you restart the kmttg service, it loses the login setting, lemm se if that fixes it..
     
  5. Feb 25, 2010 #1985 of 10413
    moyekj

    moyekj Well-Known Member

    11,142
    31
    Jan 23, 2006
    Mission...
    It will only lose login setting if you *remove* the service. If you simply stop and start service it should not lose the login setting.
     
  6. Feb 25, 2010 #1986 of 10413
    CrispyCritter

    CrispyCritter Purple Ribbon Wearer

    3,646
    1
    Feb 28, 2001
    North...
    Yes, putting a timestamp in the id makes it a recording-based id, and that seems like a step backwards for my purposes.

    I gave up on the <ignorehistory> and date filter after experimenting a while. I could have done things better using it, but there were just too many weaknesses. I had things set to last 48 hours, with only a 60 minute wait between passes of kmttg -a. Problems (and potential problems) included
    1. Shows were being copied something like 20 times before they reached the filter date.
    2. MRV times were thus affected for days following a new recording (a 50% chance of the TiVo already doing a re-transmission, slowing up HD MRV transfers a lot and making live viewing impossible.) This was probably the major reason I dropped the approach.
    3. kmttg -a was dying after a couple of days (I think lack of sufficient swap space on my server - we'll see now). Restarting was a pain if I didn't notice it within 48 hours since I had to either figure out exactly when things went down to change the 48 hour requirement in order to get my shows, or temporarily turn off the requirement, but that means the problematic shows were getting transferred again.
    4. Similar problems when the archive server was down.
    5. Meant I couldn't start archiving a series just by setting up an auto-transfer for it, since it wouldn't get the older recorded shows.

    My view is that <ignorehistory> was a necessary kludge when you didn't have per series auto-transfer options. The retransmissions weren't optimal, but there wasn't an alternative. Now you have more options. As far as I can see, if you allow a recording-based option for a series, not only does it directly implement what people want for things like news and these shows with bad metadata, but it allows you to get rid of <ignorehistory> eventually.

    Being able to set a series dependent timestamp would help several of my objections, but not all, and it still means substantial manual effort whenever the archive server or kmttg goes down for a while. I really want to be able to just start up the server and have everything work!
     
  7. Feb 26, 2010 #1987 of 10413
    moyekj

    moyekj Well-Known Member

    11,142
    31
    Jan 23, 2006
    Mission...
    Can you elaborate on that? Maybe you've spelled it out already but what kind of auto entry specific option(s) would solve this issue of multilple programs with same programId?

    P.S. My way of dealing with this (I only have 1 show that is affected) is to not set them up in auto transfers and just manually bring up kmttg GUI to choose & process the ones I want.
     
  8. Feb 26, 2010 #1988 of 10413
    CrispyCritter

    CrispyCritter Purple Ribbon Wearer

    3,646
    1
    Feb 28, 2001
    North...
    Sounds like it might be mildly useful for you as well. Please note that I'm not saying that this should be a high priority or even definitely implemented. It would be a benefit to me and to a few others I've seen messages from, but it's up to you where it fits in your priorities and needs. I'm grateful your program already does so much!

    What I envision, without knowing your code at all, is a binary flag in the series area of the auto-transfer config screen that says something to the effect of "Each recording should be viewed as a distinct show". Default of false. The implementation would be in your code when you form or get the programId. If the flag is set, the programId becomes the current programId concatenated with whatever your favorite recording specific info is, like recording time or size and url.

    That should handle everything. The modified programId would be stored in auto.history, and checked (using the same procedure) at auto-transfer time. It would allow a single auto-transfer of a recording that doesn't have a unique programId, whether due to a mistake or intentional like some news, weather, or music channel stations (I think).
     
  9. Feb 28, 2010 #1989 of 10413
    Mark Wilden

    Mark Wilden New Member

    15
    0
    Feb 25, 2008
    Very frequently, when I start kmttg, it times out while retrieving the Now Playing List. If I reset the TiVo, it's usually able to connect then.

    However, I believe the same problem is occuring when downloading a number of shows. kmttg downloads a few of them, then hangs up while trying to start downloading the next one.

    I don't think this is a problem with kmttg (which I love), but I would appreciate any tips on how I might troubleshoot/solve this problem.
     
  10. Feb 28, 2010 #1990 of 10413
    CrispyCritter

    CrispyCritter Purple Ribbon Wearer

    3,646
    1
    Feb 28, 2001
    North...
    One issue I often encounter is that if you're running more than one PC server, they will interfere with each other - evidently for some tasks the TiVo restricts itself to one at a time.

    Thus running TiVo Desktop from one server and pyTivo and/or kmttg from another will very often cause downloads to fail.
     
  11. Feb 28, 2010 #1991 of 10413
    Mark Wilden

    Mark Wilden New Member

    15
    0
    Feb 25, 2008
    That doesn't seem to be the case here, although I appreciate your response.
     
  12. Feb 28, 2010 #1992 of 10413
    moyekj

    moyekj Well-Known Member

    11,142
    31
    Jan 23, 2006
    Mission...
    Sounds like that may work. I'll look into to when I get some time. Lately I've been extremely busy with real work so very little time to do anything related to this project.
     
  13. Mar 2, 2010 #1993 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    HI, I havent been able to transfer from my Tivo for 2 days now, it has the following even after I reset the Tivo and reset the web server:

    Failed to retrieve Now Playing List from DVR-7090
    Exit code: 35
    Check YOUR MAK & IP settings

    curl: (35) Unknown SSL protocol error in connection to 192.168.137.73:443
     
  14. Mar 2, 2010 #1994 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    btw, the Tivo connects to the net over ethernet fine
     
  15. Mar 2, 2010 #1995 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    Actually when I reset the machine, quit kmttg, and restart, it comes back for a while.. is this new behavior with the 7i beta?
     
  16. Mar 2, 2010 #1996 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    Here's another possible clue this Tivo doesn't show up in the log at all
     
  17. Mar 2, 2010 #1997 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    If I try to download manually, Kmttg says that the server is busy.
    Maybe another clue is that one qsfix job in gui is counting minutes, and the other qsfix job is counting percentages. Hope this helps..
     
  18. Mar 2, 2010 #1998 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    OK I think I am closer to seeing my problem.
    A file starts to download from the Tivo. The file gets stuck in transfer. Curl gets stuck. The Tivo remains "busy" and the autolog does not refresh the playlist in autotrasnfer anymore. If I reset the Tivo, the same problem repeats.
     
  19. Mar 2, 2010 #1999 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    when I quit the curl process, the Tivo starts another transfer and stalls again at around 150 megs
     
  20. Mar 2, 2010 #2000 of 10413
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    another clue? If a Tivo has two files with the same name, same date -all transfering stalls?
     

Share This Page