pyTivo Discussion Forum Forum Index pyTivo Discussion Forum
Answers and the development of pyTivo a TiVo transcoding server
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Show total items in folders and Capture Date in List
Goto page Previous  1, 2
 
Post new topic   Reply to topic    pyTivo Discussion Forum Forum Index -> pyTivo
 View previous topic :: View next topic  
Author Message
philhu



Joined: 04 Jan 2008
Posts: 625

PostPosted: Fri Feb 22, 2008 2:54 pm    Post subject: Reply with quote

krkeegan wrote:
Agree.

I am still taking suggestions for what is best to display in the date field.


Well, I know that once a show transfers pytivo, to tivo, using TMF files from an old tivo, the date that shows up is original tivo record date.


This is stored in the metafile as 'time', see example:

time : 2002-08-09T05:00Z

Why not use that? This would make it work EXACTLY like the tivo does it. If it does not exist, use file mod date?
Back to top
View user's profile Send private message
TreborPugly



Joined: 05 Jan 2008
Posts: 55

PostPosted: Fri Feb 22, 2008 4:17 pm    Post subject: Reply with quote

philhu wrote:
krkeegan wrote:
Agree.

I am still taking suggestions for what is best to display in the date field.


Well, I know that once a show transfers pytivo, to tivo, using TMF files from an old tivo, the date that shows up is original tivo record date.


This is stored in the metafile as 'time', see example:

time : 2002-08-09T05:00Z

Why not use that? This would make it work EXACTLY like the tivo does it. If it does not exist, use file mod date?


Most videos transferred with pyTivo aren't originally from a Tivo, and don't therefore have an original tivo record date.

I prefer if the time in the NPL list is the time I transfered the file to the Tivo. When browsing in the pyTivo folders, I'd be happy with the file creation date.
Back to top
View user's profile Send private message
philhu



Joined: 04 Jan 2008
Posts: 625

PostPosted: Fri Feb 22, 2008 5:06 pm    Post subject: Reply with quote

TreborPugly wrote:
philhu wrote:
krkeegan wrote:
Agree.

I am still taking suggestions for what is best to display in the date field.


Well, I know that once a show transfers pytivo, to tivo, using TMF files from an old tivo, the date that shows up is original tivo record date.


This is stored in the metafile as 'time', see example:

time : 2002-08-09T05:00Z

Why not use that? This would make it work EXACTLY like the tivo does it. If it does not exist, use file mod date?


Most videos transferred with pyTivo aren't originally from a Tivo, and don't therefore have an original tivo record date.

I prefer if the time in the NPL list is the time I transfered the file to the Tivo. When browsing in the pyTivo folders, I'd be happy with the file creation date.


This is why I said use the metafile time field. If missing use file date, creation is best as you said, but I think if you DO have the time field filled in, it should be used
Back to top
View user's profile Send private message
edtee



Joined: 08 Feb 2008
Posts: 19

PostPosted: Fri Feb 22, 2008 5:28 pm    Post subject: Reply with quote

krkeegan,
Ok I'm not sure I'm properly following exactly what the "date" opinion poll is exactly about, but... If you are basically talking about this part I clipped(see quote below) from your post, then that is the behavior I want to see.
Quote:
i still favor the current time because at least for me when I download a show onto the TiVo it is basically like I told it to record something at that exact instant and in my mind having it appear in the NPL at that spot makes the most sense.

If your talking about order inside of the pytivo shares... I'm not sure. I'm basically happy with it as is now. I have several 100 shows in my anime dir tree alone. The creation and mod dates are wierd, due to various reasons. Also, like you, the year is often very old so... month/day alone mean little to nothing. The true critia to sort them on(besides name) is in ".my" metadata files. This works well with my other HTPC software, since even though it is an old format it is still widely supported(ie SageTV does(with a plugin) which is my current PC based PVR/HTPC software choice). Still this is another area entirely, and I'm not going to take this thread OT again(see my large post below for my original OT). I'll either start a new thread about possible .my metadata plugin support, or put in a ticket.

wmcbrine,
As for the "video.ext" changes I made. Don't worry about them.
1st(extention) was related to metadata stored in a binary format. However this extention is also a valid video file for most cases, just not me. Even I barely use it anymore, but keep them for rare legacy use in that app. I can't remember the last time I used them so maybe it's time to dump them as the data is already duped in the ".my" files anyway. Still I have many data DVDs that have them. Either way this is a situation likely only to be seen with my setup.
2nd was related to avisynth(.avs) but that has to due with a workaround I hacked for another app when playing back specific files. I have a .avs file in the same dir as the actual video. I keep my video dir well sorted and was confortable removing ".avs" from the extention list, as it would not effect any of my currently shared files adversely. Leaving it for me caused the creation of many Dshow icons in my WinXP systray, as ffmpeg tried the .avs files. These icons wouldn't go away until I moused over them, but it's not a pytivo issue. It has something to do with how the avs is calling the files, and not cleaning up. It's normally(used in other ways/apps) not an issue but given the way pytivo uses ffmpeg to test the files, the icons got out of hand in this specific case. Just to be clear both the actual file and the .avs referer transfered properly, and as expected, using pytivo.
3rd was about either me trying a test, or maybe old, ffmpeg win32 binary. It may have even been a issue in a specific fork's build that has sense been fixed. It was when I first started using pytivo, so I don't remember all the specifics. Appearantly these 3 things combined to make me go on an over-aggressive pruning of the "video.ext" file. As the current builds work basically fine with a default "video.ext". All I remove now is the 2 extentions mentioned above. There is still a "possible" bug/weird behavior with 2 files I have, but I'll start a new thread or ticket for that.

Thanks and sorry for the long post.

_________________
Love my Tivo, but I love the independent developer's software over the "official" stuff.
Back to top
View user's profile Send private message
philhu



Joined: 04 Jan 2008
Posts: 625

PostPosted: Fri Feb 22, 2008 7:08 pm    Post subject: Reply with quote

As I said, both of you are right.

UNLESS the metafile has the time keyword, which is the exact time ANY tivo recorded the show. This works exactly like Tivo NPL shows.

If I have a show from 2-10-2002 on tivo-a and send it to tivo-b, tivo-b will add it to npl as recorded 2-10-2002, NOT the time of the transfer. Check it, you'll see that is what it does.

The time keyword IS the time the tivo recorded a show. If it is there, it should be honored, like any other field read from metadata files.

If it is NOT there, then set it to file create date, that is fine
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    pyTivo Discussion Forum Forum Index -> pyTivo All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
Site is in NO WAY affiliated with TiVo Inc

Powered by phpBB © 2001, 2005 phpBB Group
phpBB SEO

Get pytivo at SourceForge.net. Fast, secure and Free Open Source software downloads
[ Time: 0.1800s ][ Queries: 17 (0.0192s) ][ GZIP on - Debug on ]