Fine, but what moyekj said and what you continue to say are completely different.

Quote:

Originally Posted by elprice7345

Both before and after the TiVo update OAD shows correctly in the NPL and sorts by OAD as desired. The dates on the TiVo are displayed correctly.

Yeah, I got that.

Quote:

Originally Posted by elprice7345

The kmttg date that is displaying differently is on the kmttg list of shows. This date displays the OAD for shows pulled before the update

That's my point. Kmttg has never shown the OAD in the list of shows from the TiVos, to my knowledge. I wish it did, and indeed I requested that very feature 3 months ago in this post. See the subsequent conversations.

Quote:

Originally Posted by elprice7345

if I used the default.txt when I pulled the shows, and the transfer date for shows pulled after the update.

I must be missing something, here. First of all, when you say "pull" I presume you mean pull from the PC to the TiVo (GoBack) not from the TiVo to the PC (TTG, or in context kmttg). To my knowledge no contents of any default.txt file has anything to do with the kmttg list of shows. The date shown by kmttg, both in the TiVo NPL window and the log file window is and always has been the date the show was recorded, according to the TiVo's response to the XML request from kmttg.

Hmm. Maybe I am getting a glimmer of what you are saying. Are you saying the date reported by the TiVo only for shows transferred back to the Tivo from the PC are now being reported differently? If so, then moyekj is most certainly correct that this is a pyTivo / TiVo issue, since kmttg only reports what the TiVo tells it. OTOH, it also doesn't help me, at all, since I don't care about the OAD of transferred material, but do often care about the OAD of material not yet transferred from the TiVo to the PC.

My apologies for not understanding the code (I’m not a programmer) or using the correct terminology and therefore lengthening what I thought was a shorter conversation.

Perhaps a screen capture from kmttg will help (attached).

The top show was pulled from my PC to the TiVo before the update. It correctly displays the OAD from the metadata file. The bottom show has exactly the same metadata, but was transferred after the update. The kmttg date for the bottom show reflects the time I started transferring the show.

The OAD displays correctly on my TiVo for both shows

I've also attached the default.txt and metadata files in case that clarifies anything.

My original point was that the TiVo reports the dates correctly, but kmttg is reporting the dates differently after the update.

Is this something that can be fixed in kmttg, is it a pyTivo issue, or is it a bug introduced on the TiVo side?

I duplicated what you guys are seeing with the new TiVo software by experimenting with some pyTivo pulls.

From what I could see from NPL XML (behavior with new Premiere software):
There is a new entry called <ShowingStartTime> in the XML in addition to <CaptureDate>. The ShowingStartTime is influenced by metadata (time first else originalAirDate) while now the CaptureDate is purely the time at which you made the transfer. If there is no time information in metadata then ShowingStartTime is close to but not equal to CaptureDate.

Older software XML (such as my S3 OLED unit):
There is no <ShowingStartTime> entry, only <CaptureDate>.

So it looks like the proper course of action now would be to use <ShowingStartTime> if available, else <CaptureDate>. I'll have to implement this for next release.

My apologies for not understanding the code (I’m not a programmer) or using the correct terminology and therefore lengthening what I thought was a shorter conversation.

Perhaps a screen capture from kmttg will help (attached).

The top show was pulled from my PC to the TiVo before the update. It correctly displays the OAD from the metadata file. The bottom show has exactly the same metadata, but was transferred after the update. The kmttg date for the bottom show reflects the time I started transferring the show.

The OAD displays correctly on my TiVo for both shows

I've also attached the default.txt and metadata files in case that clarifies anything.

My original point was that the TiVo reports the dates correctly, but kmttg is reporting the dates differently after the update.

Is this something that can be fixed in kmttg, is it a pyTivo issue, or is it a bug introduced on the TiVo side?

Ed

It has nothing to do with code or terminology. The problem is that you continue to misunderstand what you are seeing. Before the update there were two date fields, the OAD and the recording date. What kmttg was displaying was the recording date, which it sees as "Capture Date". Now there are three fields, the OAD, the date of the original recording, and the date it was transferred which is what kmttg now sees as the "Capture Date". Only the first two are displayed by the TiVo.

As I said before, the "time : OAD" entry in your default.txt file simply instructs pyTivo to set the record date/time to the same value specified for the originalAirDate.

It is not a bug in pyTivo, the TiVo s/w or kmttg and in fact, IMHO, makes "capture date" more accurate as it now reflects the actual date/time the recording was made on that TiVo, rather than the date/time of the source recording.

Having said that, I am in favor of the proposed change to kmttg.

One more thing. If you ever end up with episodes of a series whose OAD is prior to @1970, having time : OAD is problematic as it might cause the TiVo to crash.

I have been having problems with encoding recordings from CBS (1080i) downloaded via kmttg. The download and decrypt works fine, but ffmpeg seems to hang, leaving just a 42mb file. I am using this custom profile I created for use with AirVideo:

I use the same profile for encoding shows off of other 1080i channels (like NBC) just fine, it only seems to fail on CBS shows, and even then not ALL the time, but enough to be annoying. I've seen this on BBT, HIMYM, and CSI.

If I run the kmttg-generated encode command-line manually, I'll get this:

So it seems to be hanging on that "invalid timestamps" message. Is this an example of where something like QSF would help? I'm running kmttg on Linux so I don't have access to VideoRedo but I'm wondering if that's even the cause. Any ideas? Thanks!

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. | To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Quick encoding question ...
So it seems to be hanging on that "invalid timestamps" message. Is this an example of where something like QSF would help? I'm running kmttg on Linux so I don't have access to VideoRedo but I'm wondering if that's even the cause. Any ideas? Thanks!

Yes, QSF most likely would fix the problem. Note that on Linux (or any platform) you can use ProjectX for QSF step, so no need for VRD as long as you don't mind losing captions.

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. | To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

For example, "Two and a Half Men" recorded Thu 11/1 is giving me episode # 25849648.
I thought perhaps it was some weird bug in kmttg but checking the NPL XML from the TiVo that's exactly how it shows up there.
Then I thought perhaps shows with more than 9 seasons perhaps were screwed up with 20.2.2 but I see for example "Dancing with the Stars" which is season 15 with correct episode #s so that's not it. Perhaps it was just a glitch in guide listings for that particular "Two and a Half Men" episode...

For example, "Two and a Half Men" recorded Thu 11/1 is giving me episode # 25849648.
I thought perhaps it was some weird bug in kmttg but checking the NPL XML from the TiVo that's exactly how it shows up there.
Then I thought perhaps shows with more than 9 seasons perhaps were screwed up with 20.2.2 but I see for example "Dancing with the Stars" which is season 15 with correct episode #s so that's not it. Perhaps it was just a glitch in guide listings for that particular "Two and a Half Men" episode...

Well both my Premieres have 20.2.2 and I am seeing weird episode #s for "Two and a Half Men", but the two facts are not related. The most recent episodes show ep #s of 25849648, 25819482, and 25819479 but they were recorded on and remain on my THD.

Well both my Premieres have 20.2.2 and I am seeing weird episode #s for "Two and a Half Men", but the two facts are not related. The most recent episodes show ep #s of 25849648, 25819482, and 25819479 but they were recorded on and remain on my THD.

OK thanks, so I think that proves it's a guide issue of some sort, not related to 20.2.2.

This contains new RPC "Deleted" tab which allows you to see and recover shows from Recently Deleted folder.

Also adds a "Include History" boolean to the "Won't Record" tab that when enabled means past history will be included in the table so that one can explore why certain shows of interest did not record in the past.

Finally includes update discussed above to properly list record dates for shows transferred to TiVos running the new 20.2.2 software.

For example, "Two and a Half Men" recorded Thu 11/1 is giving me episode # 25849648.
I thought perhaps it was some weird bug in kmttg but checking the NPL XML from the TiVo that's exactly how it shows up there.
Then I thought perhaps shows with more than 9 seasons perhaps were screwed up with 20.2.2 but I see for example "Dancing with the Stars" which is season 15 with correct episode #s so that's not it. Perhaps it was just a glitch in guide listings for that particular "Two and a Half Men" episode...

I saw the same episode issue before and after the update, but only with 2.5 Men.

For an XL4 (or any series 4 machine) you should be using "Enable iPad style delete task" not "Enable TivoWebPlus Delete task".
(You also have to turn on "Enable iPad style communications with this TiVo" under Config-Tivos for that TiVo if you haven't done so and you have to refresh the NPL with that enabled before you will be able to delete).

This contains new RPC "Deleted" tab which allows you to see and recover shows from Recently Deleted folder.

Also adds a "Include History" boolean to the "Won't Record" tab that when enabled means past history will be included in the table so that one can explore why certain shows of interest did not record in the past.

Finally includes update discussed above to properly list record dates for shows transferred to TiVos running the new 20.2.2 software.

This contains new RPC "Deleted" tab which allows you to see and recover shows from Recently Deleted folder.

Also adds a "Include History" boolean to the "Won't Record" tab that when enabled means past history will be included in the table so that one can explore why certain shows of interest did not record in the past.

Finally includes update discussed above to properly list record dates for shows transferred to TiVos running the new 20.2.2 software.

Thanks for the new features. The Deleted Files tab will be very helpful.

I just figured out how to permanently delete shows using RPC so next release will add a "Permanently Delete" button to this tab. There have been cases where I've wanted to purge the entire Recently Deleted folder but via the TiVo you can only do 1 show at a time, so being able to select and delete all at once will be useful.

Just figured out how to use kmttg to manage conflict resolution between two tivos. GREAT FEATURE!

In using it, I run into some things that I either dont know how to do or are not there so some help please.

Once a recording is completed on an alturnate tivo, is there an easy way to transfer the recording to where it should be? IE highlight a recording in the NPL and ask kmttg to tell tivo to transfer the recording?

Would be great if the wont record tab could display conflicts for ALL tivos rather than just one at a time.

When a conflict is shown, an easy way to move the recording to a different tivo?

__________________
Current : Roamio Base with 2TB drive and 2 Premieres and a mini. OTA. kmttg, pyTivo, running with a 78TB Synology 1511 NAS....serving up the world.

Setup help for pytivo under windows: To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Once a recording is completed on an alturnate tivo, is there an easy way to transfer the recording to where it should be? IE highlight a recording in the NPL and ask kmttg to tell tivo to transfer the recording?

No. But for series 4 units MRS makes it seamless to play a show from remote unit so why bother to move the show?

Quote:

When a conflict is shown, an easy way to move the recording to a different tivo?

That's already there. Change the TiVo pulldown to the TiVo you want to record the show on. Then select the show in the table and click on 'Record'.

Same thing for 'Season Premieres', 'Search' and 'Guide' tabs - you can change TiVo selection to 'Record' or 'Season Pass' to a specific TiVo of your choosing. Note also that for 'Won't Record' the ToDo lists of all configured units is collected so for cases when a show won't record on 1 TiVo but will on another it will be indicated in a different color, and if you click on the entry it will tell you which TiVo it will record on.
This kind of multi TiVo collaboration is something that's not there on the iOS/Android apps, coupled with the fact I can do it outside my LAN as well. I do most of my TiVo conflict management away from home.

Main reason for wanting to transfer the recording is that the NPL is not integrated between the two tivos. The user has to know the recording was done on a different unit than the one they are viewing and go there to start the stream. Not user frinedly.

Also for us, all recordings we actually watch are on one box, not scattered among several. Would not matter if the NPL was integrated......

Anyway, a workaround? I would think selecting the recording for transfer with the correct options including push configured correctly could accomplish what I am after even if via 2 seperate transfers. Would be nice if there was a way to initiate a MRV transfer via kmttg though.

Using the transfer to pc and then push to the other tivo idea, what would be the most expedient method to do this and preserve as much metadata as possible along with grouping?

__________________
Current : Roamio Base with 2TB drive and 2 Premieres and a mini. OTA. kmttg, pyTivo, running with a 78TB Synology 1511 NAS....serving up the world.

Setup help for pytivo under windows: To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

I do most of my watching from 1 box as well. It's very easy to see the NPL of another unit though and now with 20.2.2 HDUI even the 'Play' shortcut works to initiate MRS of a show from another unit, so the behavior is practically the same as having a local NPL. Making a copy of a show from 1 TiVo to another is very clumsy because now you have 2 places to remember to remove a show. I never use MRV anymore.
So what's hard about viewing NPL of another TiVo? Yes you have to navigate to bottom of NPL to get to another TiVo, but the '->' button on remote makes that easy. So yes there's a couple of extra remote clicks to get to listings on another TiVo but to me that's a lot cleaner than making copies of shows just for the purposes of viewing on a different TiVo.

Main reason for wanting to transfer the recording is that the NPL is not integrated between the two tivos. The user has to know the recording was done on a different unit than the one they are viewing and go there to start the stream. Not user frinedly.

Also for us, all recordings we actually watch are on one box, not scattered among several. Would not matter if the NPL was integrated......

Anyway, a workaround? I would think selecting the recording for transfer with the correct options including push configured correctly could accomplish what I am after even if via 2 seperate transfers. Would be nice if there was a way to initiate a MRV transfer via kmttg though.

Using the transfer to pc and then push to the other tivo idea, what would be the most expedient method to do this and preserve as much metadata as possible along with grouping?

Push transfers very little of the metadata and episodes of a series will not be grouped with episodes recorded on the destination TiVo. Strangely enough, maximum metadata transfer is a pull from a computer using pyTiVo and a text metadata file. So you have to transfer it w/create metadata file and decode options set then pull it to the other TiVo.

I thought I asked this before, but I don't see it mentioned in the past few pages (since I got my Premiere 4), or I missed it..

When downloading the Now Playing list from my Premiere 4, it is FAST.. But it VIRTUALLY always (but I could swear once or twice it did not) downloads in 16 show chunks, rather than 128 with my Tivo HD. Even 16 at a time, it is a zillion times faster than the Tivo HD…

But it would be EVEN FASTER if it downloaded 128 at a time. Why does it download only 16 at a time? Is this a Premiere vs. previous Tivo limitation?

Also, I tried turning on iPad style communication, and got an exception about a bunch of missing graphic images (for the remote). I haven't checked the site yet, I think this MIGHT be mentioned… But the recommended upgrade path of "just replace the jar file" isn't always sufficient in times of changes like this. So I guess I'm just pointing this out, and maybe the prefs file should live outside the folder in a place that wouldn't be blown away if I just replaced the previous entire package with the new one. (I really wanted to try out the 'delete' function, even though I'm wary to try it at first. Being able to download a show then delete it from kmttg is intriguing..)

I thought I asked this before, but I don't see it mentioned in the past few pages (since I got my Premiere 4), or I missed it..

When downloading the Now Playing list from my Premiere 4, it is FAST.. But it VIRTUALLY always (but I could swear once or twice it did not) downloads in 16 show chunks, rather than 128 with my Tivo HD. Even 16 at a time, it is a zillion times faster than the Tivo HD…

Yes it's something TiVo changed in their software for series 4 TiVos. Not sure why they made it so small...

Quote:

Also, I tried turning on iPad style communication, and got an exception about a bunch of missing graphic images (for the remote). I haven't checked the site yet, I think this MIGHT be mentioned… But the recommended upgrade path of "just replace the jar file" isn't always sufficient in times of changes like this. So I guess I'm just pointing this out, and maybe the prefs file should live outside the folder in a place that wouldn't be blown away if I just replaced the previous entire package with the new one. (I really wanted to try out the 'delete' function, even though I'm wary to try it at first. Being able to download a show then delete it from kmttg is intriguing..)

Download the latest .zip and just unzip right over your current installation allowing overwrites. Configuration files are not part of the .zip so will remain unaffected. This is always the recommended way to upgrade since once in a while it's more than just the .jar file that gets updated.