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 23, 2010 #1961 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    The problem with checking for output file for qsfix is if you use tivodecode then the output mpeg file of qsfix is same as input mpeg file. Therefore for that case it doesn't make sense obviously to check for existence of output file.

    However for next release I've added an additional check such that if input file to qsfix is a TiVo file and corresponding output mpeg file already exists then qsfix is not scheduled if overwrite files option is disabled.
     
  2. Feb 23, 2010 #1962 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    Per documentation you can add ignorehistory entries to auto.ini file:
    <ignorehistory>
    SH1940720000
    ...

    So if you just copy lines out of auto.history to auto.ini file under <ignorehistory> section then that would be easy way to set a bunch of exceptions. I think perhaps you are asking if you can get away with the extra text following the program id? I'm not exactly sure, but a brief look suggests that may be OK.
     
  3. Feb 23, 2010 #1963 of 10616
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    Thanks for the change with Tivo name check for qsfix!
    My issue is that alot of non-duplicate shows have duplicate names because there is no extra text such as this SH011721360000 Street Court
    blocking with no-overwrite is a life saver.
    For now I have history.log erasing after 12 hours, and kmttg ignoring tivo older than 12 hours, so that should get rid of loops.
     
  4. Feb 23, 2010 #1964 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    The extra text doesn't really mean anything to kmttg. It's just to help you identify what the show is. The only thing that matters is the programId. i.e. So simply SH011721360000 without any text following is sufficient, and that's all that is needed if you add exceptions to auto.ini under <ignorehistory> keyword.

    If you are having problem with duplicate file names for different shows then you should consider modifying your File Naming template to include the recorded date of the program.
     
  5. Feb 23, 2010 #1965 of 10616
    Stormspace

    Stormspace Electrocuted by TiVo

    5,171
    0
    Apr 13, 2004
    Hartsville, SC
    Anyone else seen MS Security Essentials peg the processor when this app is running?
     
  6. Feb 23, 2010 #1966 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
  7. Feb 23, 2010 #1967 of 10616
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    will qsfix loop for <ignorehistory> files?
     
  8. Feb 23, 2010 #1968 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    Don't understand the question. The meaning of programId entries under <ignorehistory> tag is that in auto transfers mode kmttg will never consider those shows as "already processed", which means if auto transfers matching matches a show with one of these programId entries then it will always try and process it. So yes, it's very possible that this will force certain shows to be processed over and over which may or may not be what you want. As you mentioned before you can use the date filtering option to prevent processing of recordings older than a certain amount of time.
     
  9. Feb 23, 2010 #1969 of 10616
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    yes that's what I was asking, thanks
     
  10. Feb 24, 2010 #1970 of 10616
    caddyroger

    caddyroger New Member

    1,730
    0
    Mar 14, 2005
    Some where...
    I am running windows 7 pro and kmttg v0p7i. I got this reading this afternoon.

    java.lang.ArrayIndexOutOfBoundsException: 13
    at sun.font.FontDesignMetrics.charsWidth(Unknown Source)
    at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
    at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
    at javax.swing.text.Utilities.getTabbedTextOffset(Unknown Source)
    at javax.swing.text.PlainView.viewToModel(Unknown Source)
    at javax.swing.text.FieldView.viewToModel(Unknown Source)
    at javax.swing.plaf.basic.BasicTextUI$RootView.viewToModel(Unknown source)
    at javax.swing.plaf.basic.BasicTextUI.viewToModel(Unknown Source)
    at javax.swing.text.DefaultCaret.moveCaret(Unknown Source)
    at javax.swing.text.DefaultCaret.mouseDragged(Unknown Source)
    at java.awt.AWTEventMulticaster.mouseDragged(Unknown Source)
    at java.awt.AWTEventMulticaster.mouseDragged(Unknown Source)
    at java.awt.Component.processMouseMotionEvent(Unknown Source)
    at javax.swing.JComponent.processMouseMotionEvent(Unknown Source)
    at java.awt.Component.processEvent(Unknown Source)
    at java.awt.Container.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)
    What could be causing this.?
     
  11. Feb 24, 2010 #1971 of 10616
    StanSimmons

    StanSimmons Senior Moment Member

    4,717
    0
    Jun 10, 2000
    Flower...
    I had the same issue with my Vista x64 setup.

    moyekj responded:
    It hasn't seemed to effect my system, so I'm just gonna ignore it too.
     
  12. Feb 24, 2010 #1972 of 10616
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    if I create dummy .mpg.qfix files to stop kmttg from looping files tagged with <ignorehistory>, will this work? or will videoredo overwrite my dummy file? it's hard for me to tell because I have so many files qued
     
  13. Feb 24, 2010 #1973 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    No that won't work. Replace your kmttg.jar with a beta version of kmttg.jar in this zip file. It contains the change I mentioned above where qsfix task will not be scheduled if input file is TiVo and you have the "Overwrite existing files" option disabled and the output mpg file already exists. Obviously stop kmttg service 1st before replacing the jar file and then restart service.
     
  14. Feb 24, 2010 #1974 of 10616
    miguelakiira

    miguelakiira New Member

    37
    0
    Jan 26, 2010
    great, running now, will let you know if there are any issues, it knows to look for the mpg in the mpg directory set by the config right?
     
  15. Feb 24, 2010 #1975 of 10616
    CrispyCritter

    CrispyCritter Purple Ribbon Wearer

    3,652
    2
    Feb 28, 2001
    North...
    Are you sure it won't work? I've been forced to play around with something similar the past few days to stop constant transfers, and my current solution seems to work. My custom script creates the appropriately named .tivo file in the upload directory and makes it a readonly file. Future transfers of the file then fail (even though I have overwrite files still set to true, which I need). It's incredibly ugly with very ugly errors in the logs and who knows whether it will break in the future, but it does work, and I'm not sure why something similar wouldn't work at a later qsfix stage.

    It seems to me that this is an example of a general problem of how to handle the auto-transfer of programs that don't have good enough metadata to accurately identify the episode for auto.history. Given your recent changes to the configure file for auto-transfer (in particular, giving series and machine dependent options), perhaps you could attack the problem directly?

    You could set up a series dependent flag in configure that indicates recordings of shows (not just episodes of shows) are to be considered different. Then for those shows, auto.history could have its programId set to the current programId concatenated with the recording time. When checking potential transfers of that series, you would do the same thing.

    That gets rid of the ugly ignorehistory and newer than 48 hours hack for many purposes, as well as all the extra transfers that happen because of that. (I have problems with the 48 (or whatever) hours settings in that kmttg -a is dying occasionally, or that computer is not communicating or whatever, and I often want to auto-transfer older shows.)

    This solution is not optimal for my particular need - I have a series that has much generic info (no episode number, title, or description), but does have an accurate original air date that could conceivably be used. But it does seem like a solution that is clean enough to be useful for lots of folks, including me.
     
  16. Feb 24, 2010 #1976 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    CrispyCritter, so I think you are talking about programs that don't have a unique programId? i.e. Different recordings of a series all have same programId? I didn't know that was very common. I have a couple of repeating manual records that suffer from that problem but didn't know it applied to non-manual recordings as well.

    In version v0p7e I tackled the problem of programs without a programId (such as pyTivo or TiVo Desktop pulls) by generating a fake id using a combination of url id & file size. So if this issue is fairly common where different recordings have same programId perhaps the best solution is to always have kmttg build its own unique id similar to what is done now for programs without one. (Auto transfers would still have to be smart and check auto.history for old style id based on programId for backwards compatibility reasons, but all new transfers would get their own kmttg generated id perhaps based on url id & recording time).

    I welcome any further inputs on this important issue. Perhaps there is a better tracking system for preventing repeated downloads than a history file? I'm open to suggestions.
     
  17. Feb 24, 2010 #1977 of 10616
    cweb

    cweb Member

    106
    0
    May 29, 2004
    I have the "Allow multiple VideoRedo jobs at once" box checked", but still only one VideoRedo job is running at a time. Is there some thing else I need to enable? Do services need to be running? (I do get the VideoRedo initial GUI popup to momentarily appear.)
     
  18. Feb 24, 2010 #1978 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    Under Program Options tab make sure you set "active job limit" > 1 as mentioned in the tooltip for the "Allow multiple VideoRedo jobs at once" option.
     
  19. Feb 24, 2010 #1979 of 10616
    CrispyCritter

    CrispyCritter Purple Ribbon Wearer

    3,652
    2
    Feb 28, 2001
    North...
    Sorry for the delay in responding, I wanted to make certain that the shows all have the same programId. Tough to do since it's not part of the metadata that's saved; the only way I can see to get it is in the auto.history.

    Yes, the shows all have the same programId. This is Cartoon Network which, along with Comedy Central, is known for the lack of attention to such things. I had thought from other peoples' reports that it wasn't all that uncommon, with news shows and things like "The Daily Show" being the main culprits. By the way, I was partly incorrect - my episodes don't in general have the correct original air date - it's a generic date from the start of the series.

    I like your current episode-oriented history, and think you should keep it as the default. It allows the easy collection of shows in reruns - that would be a mess if you were getting multiple copies of the same old re-run. It also (mostly) solves the problem of the same show being recorded on multiple TiVos, and having to be careful about multiple downloads. I think it works well the vast majority of the time.

    Where it fails is when the broadcasters don't fulfill their obligations and don't have the proper metadata associated with the show. Rather than having kmttg try to figure out what to do for all possible combinations of missing data, I think it would be cleaner for these particular series for kmttg to construct a recording specific id, like you suggest, to allow the shows to be transferred exactly once. Since it's hard for kmttg to tell if there's missing data, I would think it would be easier for the user when setting up the auto-transfer to tell kmttg to use the recording specific id for this series.

    On a related note, is there any reason why the programId is not included in the available meta-data? There are shows out there that have a good programId, but have incorrect episode numbers. "Buffy the Vampire Slayer" is almost always episode number 2 or 3, but the encoding of the programId has a correct episode number in it. It would be handy to have that info around - I'm currently editing the .txt file by hand for Buffy!
     
  20. Feb 25, 2010 #1980 of 10616
    moyekj

    moyekj Well-Known Member

    11,264
    78
    Jan 23, 2006
    Mission...
    I still think it would be cleaner and easier to construct a truly unique "kmttgid" perhaps out of programId & recorded time for every show so as to make it unique even for cases of lousy TiVo data. Having a user specify which shows are to be treated special complicates things unnecessarily.

    I'm not following you here... there's a relationship between episode numbers & programId? Last I checked pyTivo metadata Wiki page I didn't see anything about programId mentioned so never thought to include it in metadata files.
     

Share This Page