I have a show in my todo list which I first added extra time to the beginning and end.

Once this takes effect, I am unable to (in kmttg) change the beginning time back to zero. It accepts the modify, says it changed it on the tivo, but the added time to the beginning remains set.

I can change the amount of time, say from 10 minutes to 5 minutes, but cannot set it to zero.

I can change the ending extra time back to zero, however.

I restarted the program and refreshed the todo list and still could not change the extra beginning time. I then waited a day and tried this on a new show scheduled in the todo list and was able to repeat the problem.

I can go to the tivo and change it there, however. I have a 4 tuner roamio.

I can reproduce the issue, but no idea how to make it work. The startPadding coding is done same way as endPadding, just seems the Roamio doesn't honor the 0 start padding request for some reason.
Note that all of this RPC stuff is reverse engineered, so there's no user manual explaining how things should be implemented, so there's no way of knowing what works other than by trial and error.

Disabling "Show Folders" will eliminate all folders including suggestions. If you want just suggestions folder off while keeping others then no. What's the point of that anyway? It won't speed up grabbing listings up if that's what you are thinking.

I Just found the auto resolve option for the todo list. VERY cool that its able to fix recording conflicts and reschedule them on a different TiVo, however, it seems as though its not fully functioning. I have a TiVo that has a few conflicts where its supposed to record 3 shows at the same time (being a premiere it can only do 2) when I hit auto resolve, it set 1 show to record on the other TiVo, but it ignored the second conflict - which I was able to manually hit record and have it schedule on the second TiVo.... Not sure whats going on there.

Also - would be REALLY cool if auto resolve could be set as an automated option where it would check once a day (or whatever) and automatically resolve recording issues without needing to press auto resolve.

I was bored looking around kmttg and found that, AND was surprised when I saw there were a bunch of shows that never got recorded that I didn't even know I missed!

Also - would be REALLY cool if auto resolve could be set as an automated option where it would check once a day (or whatever) and automatically resolve recording issues without needing to press auto resolve

Read the tooltip associated with the "Autoresolve" button - it tells you how to run kmttg batch mode to run this function. You can use batch mode run in conjunction with your OS scheduler to schedule periodic runs of Autoresolve.

I did find an issue with callSign comparison when comparing SPs. I've fixed it for next release. As it is now basically the callSign is being ignored so it doesn't matter if it's different or not. In next release you'll be able to schedule SPs with same title but different callSigns. I confirmed the fix using "Cosmos: A Spacetime Odyssey" series which currently runs on 2 different Fox channels in my lineup and I was able to create SPs for both using kmttg.

Thanks. Sorry I didn't reply earlier, was out of town w/no Inet access.

I can reproduce the issue, but no idea how to make it work. The startPadding coding is done same way as endPadding, just seems the Roamio doesn't honor the 0 start padding request for some reason.
Note that all of this RPC stuff is reverse engineered, so there's no user manual explaining how things should be implemented, so there's no way of knowing what works other than by trial and error.

No biggy, I'm just beta testing the latest versions and reporting something I found to help out. As I mentioned, it can be adjusted on the tivo itself, it's just much easier to use kmttg

Second, I think it would be an improvement if KMTTG were to add processing jobs to the job queue for older (by recording date/time) shows before newer shows. When it is running as a service, this probably doesn't make a lot of difference, since each series is likely to have only one new episode since the previous fetch of Now Playing List.

When running Auto Transfers in GUI, if multiple episodes have accumulated since the last run (or while first setting up Auto Transfers), the timestamps on downloaded files will end up in the same order as they were received from the TiVo. For Roamio Plus (and I think S3) NPL is sent in reverse chronological order, so that most recently recorded programs are listed first.

If all other TiVo's send NPL in same order (most recent first), it should be relatively simple to just reverse the Now Playing List received from TiVo when processing Auto Transfers. If there is an option to limit number of listings downloaded, this should still be OK, since the TiVo will still be sending most recent programs first.

The support for episode numbering (special thanks for going above and beyond the old way of just using episode number in meta-data if it happened to be present) means that much of the time, properly named shows can be sorted. After seeing how well the episode numbering worked, I dropped "(Recorded 2014...) from the file naming scheme. It wasn't generally sortable by that, nor was I using times (if recorded time was even an option).

In some cases, broadcast order does not match episode number order. Having an easy way to sort (by file date/time in explorer on the PC) to sort as a proxy for recording date comes in handy at times. One particular example is "The Three Stooges". There is a 2 or 3 hour block of 20 minute shows. The network does not always start and end episodes at the times specified in guide, so the tail of one show often ends up in the head of the next or vice versa. Fixing this via VideoRedo or some other editor is easier when date on PC's disk is same order as time recorded on TiVo. They are not broadcast in episode order. Over time, the Auto Transferred episodes end up in an order (by file creation/modification time) like this:

Lately, I have been using KMTTG in GUI mode only, with the service disabled. Every few days, I "Run Once in GUI" from the Auto Transfers menu.

With version v1p0q (and I think, but am not sure, with v1p0p), after the jobs created by AutoTransfer have completed, I return to the PC (perhaps a day or more after completion), and Refresh the list from Tivo (Roamio Plus, if that matters), and a side effect of refreshing the list is a new set of jobs are queued by the AutoTransfer process. I am quite sure that I'm NOT pressing Auto Transfers/Run Once in GUI again. It doesn't happen every time. Maybe it is related to time of day, though I have not kept any log to see what the pattern is. It could also be that it happens one time for each time I "Run Once in GUI", but again, I have not kept a detailed log.

This isn't catastrophic - odds are that I was going to do it anyway, but it can be annoying, for example, if I had planned on rebooting (monthly updates for Windows, or some other reason) before queuing up the Auto Transfers.

This may have already been reported - I only reviewed the last couple pages of posts, so if it is a duplicate, I apologize.

Update: It occurs to me that this might be related to having 2 TiVo's configured in KMTTG, but with only one (Roamio Plus) actually online, with the S3 not currently active. After the most recent unsolicited Auto Transfer, I refreshed several times, and everything behaved normally. Stopping and starting KMTTG also behaved normally. After the reboot for this month's patches, I'll see if there is exactly one extra set of Auto Transfers triggered by a normal refresh. (I may need to wait overnight for the first AT to finish.)

dredwing, the reverse chronological order (older first) makes some sense and was easy enough to implement, so it will be in next release.
Can't reproduce the "Run Once in GUI" issue you described above.

I'm on a mac and when I click "configure" I am getting errors. Here is the stack trace. Bad java install?

java.lang.NullPointerException
at com.apple.laf.AquaComboBoxUI$1.itemStateChanged(AquaComboBox UI.java:97)
at javax.swing.JComboBox.fireItemStateChanged(JComboBox.java:12 25)
at javax.swing.JComboBox.selectedItemChanged(JComboBox.java:128 2)
at javax.swing.JComboBox.contentsChanged(JComboBox.java:1329)
at javax.swing.AbstractListModel.fireContentsChanged(AbstractLi stModel.java:118)
at javax.swing.DefaultComboBoxModel.setSelectedItem(DefaultComb oBoxModel.java:93)
at javax.swing.JComboBox.setSelectedItem(JComboBox.java:578)
at com.tivo.kmttg.gui.configMain.read(configMain.java:866)
at com.tivo.kmttg.gui.configMain.display(configMain.java:160)
at com.tivo.kmttg.gui.gui$25.actionPerformed(gui.java:1011)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButto n.java:2018)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractB utton.java:2341)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultBu ttonModel.java:402)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel .java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItem UI.java:833)
at com.apple.laf.AquaMenuItemUI.doClick(AquaMenuItemUI.java:157 )
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased (BasicMenuItemUI.java:877)
at java.awt.Component.processMouseEvent(Component.java:6505)
at javax.swing.JComponent.processMouseEvent(JComponent.java:332 0)
at java.awt.Component.processEvent(Component.java:6270)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4861)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container. java:4832)
at java.awt.LightweightDispatcher.processMouseEvent(Container.j ava:4492)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java: 4422)
at java.awt.Container.dispatchEventImpl(Container.java:2273)
at java.awt.Window.dispatchEventImpl(Window.java:2719)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Pro tectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Pro tectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:708)
at java.awt.EventQueue$4.run(EventQueue.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Pro tectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDis patchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispat chThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDis patchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread. java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread. java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91 )

I'm on a mac and when I click "configure" I am getting errors. Here is the stack trace. Bad java install?

Other Mac users have reported this too. It seems to be related to "config-Visual-look and feel" setting, but I don't have a Mac to try and debug the problem. Try different settings there to see if there's one that doesn't produce the problem.

dredwing, the reverse chronological order (older first) makes some sense and was easy enough to implement, so it will be in next release.
Can't reproduce the "Run Once in GUI" issue you described above.

One other detail I forgot to mention - I also have a TiVo Mini on the network.
I did confirm that the "Run Once in GUI" issue happens for exactly one extra time (the first refresh after a "Run Once in GUI" was intentionally started, assuming the ROiG tasks have completed). I also confirmed that the problem disappeared when I removed the S3 (which is not powered on) from the KMTTG configuration.

Thanks for the quick response on the feature request. A couple more feature requests.

1) It would be nice if the summary at end of Auto Transfer reported the number of programs scheduled for processing, in addition to the message indicating how many matches were found.

2) An easy way to remove an episode from the transfer history, probably with an interface similar to that for adding an episode TO the transfer history. This would be useful in cases where a download was corrupted, or an incomplete program was recorded. For this to have the desired effect, user would need to delete the problem episode from TiVo before removing it from transfer history. For cable channels that repeat an episode several times over a couple weeks, there would be a good chance of Auto-transferring the episode after re-scheduling it manually on TiVo. For shows that only air once a week, there would be a chance to automatically re-capture the episode when the network repeats episodes during a season, or perhaps to get the program from syndication in another year or so.

Thanks again for a great program!

Added 03-23-2014
Hmmm... a couple hours after I posted this, I realized the inherent contradiction. If the show is in the now playing list, where it can easily be selected and marked for removing the program ID from download history, it will immediately become a candidate for download. Since there was something wrong with the program to start with, we probably do not want to re-download the current episode. Perhaps some kind of "remove from history and remotely delete from the tivo" or "remove from history and tell user to delete it" could work. As long as kmttg can remember the program ID for a few seconds, it should be possible to delete first, then remove from download history, just so a badly timed Auto-download doesn't catch the program during a small window of vulnerability.

And tonight we have another of the events that might lead to partial recordings for which this feature would be useful - CBS Sports running long, and pushing back east coast start and end times for 60 minutes, The Amazing Race, The Good Wife and The Mentalist. (Padding The Mentalist as part of season pass is another way to minimize impact of sports delays, but having multiple ways to solve a problem is useful.)

Another scenario where clearing a program from download history is useful - when the network broadcasts an episode that does not match the guide data (particularly if they air a rerun in a slot that the program guide has labeled as a new episode), then the following week airs the episode with correct guide data. You will probably need to manually record (on TiVo) next weeks episode (or change season pass to record ALL episodes), but it would be useful for KMTTG to download the episode that has content matching guide data.
(My description is a bit unclear - hopefully you can envision the scenario I am describing.)

Last edited by dredwing; 03-23-2014 at 08:05 PM..
Reason: pointing out the catch...