Yeah pyTivo checks for ffmpeg compatibility the first time it opens a folder, it is then cached so it should be fast. TiVo.Net checks for compatibility when it loads. I can't decide what is preferable.

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

A much better place to receive pyTivo help and updates.

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

I prefer the scanning the first time a folder is opened for a few a few reasons.

1) Ever time you start your computer do you want to to scan all your files?

2) Do you want to keep the status of every file in memory? Right now it will only keep the 100 most recently seen.

3) Finding an item in the tivo menu gets painful when there are more the 40 items. I just opened a folder with 60 videos and it took about 5 sec. And I sort my videos in to folders and sub folder so I never have more than 22 in a folder.

The other file was a .wmv file and it complained about top crop or something like that. Both files transfer OK with Tivo.Net.

Seems like a pretty old build of ffmpeg (??). The one that comes with Tivo.Net is about twice the file size (??)

Hah !! Substituted the ffmpeg_mp2.exe that comes with Tivo.Net and it worked, although the video was blocky compared to transfering with Tivo.Net. Looks like the encoding bitrate is too low -- any way to adjust that?

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Doh! Ok, I'll check into making that happen. I did try it with Python 2.3.4 though, it seemed to at least start up but never showed in my NPL. I fired up tcpdump and it appears pyTivo is broadcasting out my public ip address and not the LAN one. I had the exact same problem with Tivo.Net until Pipakin addeded the option of picking which ip address to bind to.

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.

Hah !! Substituted the ffmpeg_mp2.exe that comes with Tivo.Net and it worked, although the video was blocky compared to transfering with Tivo.Net. Looks like the encoding bitrate is too low -- any way to adjust that?

Hmm okay let me check out Pipakin's windows ffmpeg binary. If it is an updated version we can replace ours.

Choppy video?? Hmm i don't have a setting to change the bit rate, but I would be surprised if that was the issue. Currently the bit rates are hard coded at 4096kbits/second video and 192kbits/second audio.

I will look into adding this as an option the config file.

Quote:

Originally Posted by ocntscha

I fired up tcpdump and it appears pyTivo is broadcasting out my public ip address and not the LAN one.

Hmm okay, let me see if I can add an ip as an option in the config file

Feature Request
Ok so it would be nice to add metadata. But I don't know what is the best way to handle this:
1. I would love to use embedded data in the video file itself such as RIFF data. This would be ideal, any changes to the file would not destroy the metadata. However I dont think there is a good python module for doing this without requiring a major install.

2. Central DB. This is still very clean, but changing the name or moving an video files would delete the metadata. Additionally the loss or damage to the main DB would mean the loss of ALL data.

I believe that the newer version of ffmpeg that is packaged with Tivo.net changed the way the bitrate was defined. In the old version, you specified in kbytes, in the new version you specify in bytes. I seem to remember when Pipakin switched over and had this same problem of the resolution suddenly going through the floor.

I believe that the newer version of ffmpeg that is packaged with Tivo.net changed the way the bitrate was defined. In the old version, you specified in kbytes, in the new version you specify in bytes. I seem to remember when Pipakin switched over and had this same problem of the resolution suddenly going through the floor.

Sorry I don't have a link to that post in the other thread.

Yep, in the newer version you have to use "4000k" instead of "4000" (for example). I'm going to look at transcode .py to see if there is an obvious place to insert the 'k'.

Thus just copy a better version of ffmpeg_mp2.exe (e.g., the one that comes with Tivo.Net) in to replace the original, and make this simple edit to transcode.py and you are in business. (Warning: have not tried it as a service yet.)

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Thus just copy a better version of ffmpeg_mp2.exe (e.g., the one that comes with Tivo.Net) in to replace the original, and make this simple edit to transcode.py and you are in business.

Yup that will do it, and it won't have any bad effects when running as a service.

Edit Ok adding K to the older version of ffmpeg has no negative effects. So I will change this in the release tonight. Other things in the list for tonights release: One final tweak to the transfer error.

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

A much better place to receive pyTivo help and updates.

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

I'm having trouble with several files I transfer that are 1 to 5 minutes long. They transfer and view fine and ask if you want to save them. However when you try to play them from the NPL they cannot be played and it says TiVo was unable to record them perhaps because the signal was lost. (I sse this sometimes with TiVo.Net too)

This excerpt starts with the final 2 output lines from ffmpeg when it finished encoding. The time it gives is exactly correct for the clip. Notice the "GET ....... 206" that comes next. Is that a clue as to the problem?

Also, you posted on the Tivo.Net thread that the solution to end of transfer involved sending TiVo a 206 with certain headers. I don't see those headers in the GET....206 command, but I don't know if they should be visible there.

You may notice the bitrate is well below 4096k. That's partly because I had changed it to 3072k in transcode.py as an experiment to see how it affected this problem. The behavior was the same when it was at 4096k. The WMV file I'm transfering is highly compressed to around 600 kbps, and I don't think ffmpeg can meet the high bitrate targets. (Perhaps that is part of the problem?)

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

I'm having trouble with several files I transfer that are 1 to 5 minutes long. They transfer and view fine and ask if you want to save them. However when you try to play them from the NPL they cannot be played and it says TiVo was unable to record them perhaps because the signal was lost.

Hmm I not sure what is causing this. But I noticed that Desktop sent 3 hexcodes at the end of a transfer. Adding this seems to help, I think maybe they mean end of file??

Anyways try the new version, I hope that it will solve your problem.

Quote:

Originally Posted by dlfl

Notice the "GET ....... 206" that comes next. Is that a clue as to the problem?

Nope that is exactly how it should work. The "GET" command comes from TiVo requesting more of the file that isnt there. The 206 is our response back to TiVo the headers are sent but not printed in the output.

Quote:

Originally Posted by dlfl

I don't think ffmpeg can meet the high bitrate targets. (Perhaps that is part of the problem?)

Hmm, i am not sure what you mean here. ffmpeg handles fine for me at 4096K. I am able to transcode about 30% faster than realtime. But this is on linux and using a 2.8GHz processor. Lower bitrates should run better on slower machines.

NEW VERSION
Just minor changes:
- Added some final code to end transfers properly
- Changed code to allow for use of newer version of ffmpeg

I didn't switch to pipakin's ffmpeg because it is pretty large. In fact I think we should pull ffmpeg out of the distro so people dont have to download it for every new version. Armooo what do you think?

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

A much better place to receive pyTivo help and updates.

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

Three WMV files (1, 2.5 and 5 mins long) that would transfer but not play later from the NPL using 165 now both transfer and play later OK with 166.

Thanks KRKeegan and Armooo

The only slight glitch was at the end of transfering the 1 min clip. It stopped and gave the wait-and-hit-play message. I had to do that several times, taking perhaps 20 seconds before it finished up in a normal way. This is not a result of slow video serving from my PC -- it was well ahead of real-time at all times during the transfer. It must be a file-length issue, I would think.

@KRKeegan:
I'll try to clarify what I was trying to say before. Normally with a 4096k bitrate specified, ffmpeg will encode at that rate plus a few 100 kbps for the audio. However for very low bitrate input files (such as my WMV's) it can't see its way clear to do this and ends up encoding with a smaller bitrate. I assume you are basing the file length estimates you send to TiVo on the specified bitrate, but the lower actual rate results in a smaller actual file size. It would be plausible to me for this to make end-of-transfer problems more likely. (???)

I am still using the ffmpeg from TiVo.Net just FYI.

I notice a delayed response to clicks when doing things in the pyTivo section of the NPL and it looks like messages are occuring about every ten seconds in the pyTivo command window. Is this timing set by pyTivo or by the TiVo itself?

Looking good so far -- thanks again

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Great program guys. I had to do a few tweaks to get things to work for me and I hope they're useful for others as well.

For one video, which as 720x304 IIRC, the select_aspect_ratio() function was coming up with negative padding values, which my ffmpeg complains about. The changes are in svn diff format in the attached aspect_ratio_change patch file.

My ffmpeg's output is formatted slightly differently, so I made a change so both the old and new formats should work. The changes are in svn diff format in the attached ffmpeg_change patch file.

I've noticed that ffmpeg seems to be called several times to get various bits of info about the video file before transcoding. I'm thinking about making a generalized file info mechanism using the LRU caching mechanism, but haven't coded it up yet as it'll be a refactor compared to the above mentioned changes.

BTW, setting the svn:eol-style property to "native" on the various files in Subversion would make things easier for me and perhaps others since I'm on a Debian Linux box and it appears others may be using Windows.

Cool great updates. Couple questions/issues.
1. I know you said you weren't sure which method you liked on scanning the files, I much prefer populating that list as fast as possible on the tv as opposed to the current way. Is there a way to put both methods in code and give us a setting for that?

2. Windows service still doesn't work, I am unfamiliar with Python so I have no clue how to "run" that without just clicking on it. The screen pops by too fast to read the error. It is in my services, but it just doesn't start properly. How can I get this error logged so I can get a better look at what might be causing it?

But thanks! the transfers are working flawlessly for me since the updates as well.

The only slight glitch was at the end of transfering the 1 min clip. It stopped and gave the wait-and-hit-play message. I had to do that several times, taking perhaps 20 seconds before it finished up in a normal way.

Yeah this is a function of how TiVo requests the file. The process works like this.
1. TiVo asks for the information about a video
2. pyTivo sends back a file size that is as large as the file could possibly be (Example 1Gig)
3. TiVo sends a get request for the Video
4. pyTivo streams the video as it transcodes
5. Stream abrubtly ends at the end of the video (Example 800MB)
NOTE: At this point TiVo is still expecting another 200MB
6. TiVo waits thinking that network traffic has slowed down the packets, TiVo seems to wait 30 seconds or so.
7. TiVo then requests the file again asking for the last 200MB
8. pyTivo responds with a 206 which tells TiVo that the file has ended and sends a short bit of code which I believe equals and End of File line.

The problem occurs in steps 6-8. Until TiVo receives the 206 response it leaves the file open expecting more to come. I don't think I can force TiVo to respond any faster. And I dont think i can just send the 206 until TiVo requests it. As for bad estimations in the file size. They dont really matter, too large just clears more space than necessary but it doesnt affect the delay at all in steps 6-8. Too small clearly would cause the video to end prematurely, so I would rather err on the much to large side than be super accurate.

I think for very short files we may always have small problems trying to play them live. I will look into this but since playing files 1 minute in length is rare I won't consider it critical.

Quote:

Originally Posted by dlfl

I notice a delayed response to clicks when doing things in the pyTivo section of the NPL and it looks like messages are occuring about every ten seconds in the pyTivo command window. Is this timing set by pyTivo or by the TiVo itself?

Hmm, the TiVo UI is a little slow, but 10 seconds sounds excessive. 10 seconds may occur the first time you load a folder after starting pyTivo. But if you exit the NPL and come back that folder should load in seconds because the info is in the cache the second time.

Quote:

Originally Posted by Zothar

For one video, which as 720x304 IIRC, the select_aspect_ratio() function was coming up with negative padding values, which my ffmpeg complains about. The changes are in svn diff format in the attached aspect_ratio_change patch file.

Oops I thought I fixed all of these issues. Thanks for the help

Quote:

Originally Posted by Zothar

My ffmpeg's output is formatted slightly differently, so I made a change so both the old and new formats should work. The changes are in svn diff format in the attached ffmpeg_change patch file.

Again thanks for the help.

Quote:

Originally Posted by Zothar

I've noticed that ffmpeg seems to be called several times to get various bits of info about the video file before transcoding. I'm thinking about making a generalized file info mechanism using the LRU caching mechanism, but haven't coded it up yet as it'll be a refactor compared to the above mentioned changes.

Hmm, I think(??) that ffmpeg is only called at most twice per file. Once to get the video info(Size, Duration, Type) which is then cached in LRU. And a second time to transcode the file. If there are places where it is calling ffmpeg unnecessarily please let me know, but I think we caught them all.

Quote:

Originally Posted by Zothar

BTW, setting the svn:eol-style property to "native" on the various files in Subversion would make things easier for me and perhaps others since I'm on a Debian Linux box and it appears others may be using Windows.

I not in charge of SVN, and I dont even know what that is so maybe armooo can fix that for you.

As for your updates, since they are not critical I will toss them into a cumulative update tonight.

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

A much better place to receive pyTivo help and updates.

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

Cool great updates. Couple questions/issues.
1. I know you said you weren't sure which method you liked on scanning the files, I much prefer populating that list as fast as possible on the tv as opposed to the current way. Is there a way to put both methods in code and give us a setting for that?

Yeah I was thinking about that too. I think this is doable.

Quote:

Originally Posted by Jabo4

2. Windows service still doesn't work, I am unfamiliar with Python so I have no clue how to "run" that without just clicking on it. The screen pops by too fast to read the error. It is in my services, but it just doesn't start properly. How can I get this error logged so I can get a better look at what might be causing it?

Hmm, the windows service has been armooo's teritory.

But to run it so you can see the errors:
1. Start->Run
2. Type "cmd"
3. browse to the folder where pyTivo is located. For example "cd c:\program files\pytivo"
4. Type "pyTivoService.py"

That will run the service in the command window, all errors will be displayed there. If you need to end a python program it can be accomplished by presseing CTRL-BREAK

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

A much better place to receive pyTivo help and updates.

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

I just transfered a 5 minute .mpg clip that was edited from a TiVo recording using VideoReDo. I thought it should have transfered without re-encoding, as stated in the first post of this thread:

Quote:

It will not transcode an mpeg that is in a format supported by tivos

However, not only did it start re-encoding, but the aspect ratio on the TV was wrong (corresponding to the 480x480 format of the file).

This same clip will go back using TiVo go back and plays with the correct AR. The VideoReDo info says the display resolution is 720x480 (but encoding resolution is 480x480), as it does for all TiVo recordings or edited versions thereof.

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Hmm, I think(??) that ffmpeg is only called at most twice per file. Once to get the video info(Size, Duration, Type) which is then cached in LRU. And a second time to transcode the file. If there are places where it is calling ffmpeg unnecessarily please let me know, but I think we caught them all.

For video, the only use of LRU that I see currently is in video.py to keep the playable or not boolean. video_info() itself should probably do an LRU internally, which would keep the other code simple.

Yea I'm not sure what's up with the service. It just spits out the usage stuff when I run it. I can try start/stop install/update/remove w/e it just does nothing. Not a big deal I may write a service myself in .net to accomplish it. Thanks for all the hard work!

For the original TiVo recording you get exactly the same thing except the name and duration are different (expected) but also the Display Size is 720x480. However the mpeg2 plays with correct AR in WMP11 and when transfered to the TiVo via TiVo go back.

Actually, I remember having this same aspect ratio problem initially with TiVo.net (which always re-encodes even TiVo compliant mpeg2's as you know). It was in response to this that Pipakin added the two choices for aspect ratio. I think if you can keep it from re-encoding the problem might vanish. I'm wondering if the "Display Dimensions" are being reported by ffmpeg to pyTivo and since they are not 720x480 pyTivo thinks it needs to be re-encoded? This could be a difference between versions of ffmpeg -- I'm using the one that comes with TiVo.net.

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

I've tested with a short DivX file and a 1.5 hour AVI (XVID + mp3). No end-of-file problems.

Score one for Zothar's aspect ratio patch, however. The AVI file was a 320x192 and without the patch it would not encode, throwing a top crop error (IIRC). With the patch it encoded fine. It ended up stretched about 9% vertically, but this probably would not be noticed by most viewers. I determined this by measuring a stop sign in one scene on the TV screen. When transfered with TiVo.net (with the correct aspect ratio choice) it was compressed vertically by about 4% -- I'm not sure my TV is any better than that.

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Ok sorry folks I am dead tired tonight. I was up at 4:30 for a bike tour before the marathon here in LA.

Zothar Alright I will agree to the bad algebra in the vertical padding. But I double checked the horizontal and I think I have that one correct. I don't know look at them both again and let me know. It has been a long time since I had algebra.

Update
Other than fixing that minor bug. I didn't do anything else tonight. dlfl I will do my best to figure out why ffmpeg is still transcoding a TiVo file. Zothar I tried to move LRUcache from video.py to transcode.video_info(), but it just gave me a headache and I think I am too tired to think properly. Jabo4 Once I move the cache to it's new location I think I can create a quick extra file that can optionally be spawned at start to query all files.

So maintenance update tonight, nothing big. Have a good night all.

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

A much better place to receive pyTivo help and updates.

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

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

...... dlfl I will do my best to figure out why ffmpeg is still transcoding a TiVo file. .....

Since I am using a different ffmpeg, it could be as simple as using Zothar's ffmpeg patch, or a similar problem related to the way ffmpeg reports file specs. I haven't looked at the patch yet.

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Note the first line was not part of the error message -- I just added a print statement in tivo_compatable() to indicate what info was being parsed from ffmpeg. Note the millisecs value is correct for the clip duration.

I repeated the transfer just to verify it did exactly the same thing. The part that transfers before the error does stay in the NPL and can be played.

I can't help suspecting this error is a result of underestimating the file size (???).

(i.e., substituting 6200 for the 4288 that was there).
The entire file transfered -- after a short while the 206 response was sent, and all was well.

This was done because this clip was recorded at TiVo Best Quality which is around 5800 kbps. Of course this is just a test hack and probably shouldn't be left that way -- it overestimates re-encoded files by way too much. There needs to be a more accurate file size estimate for TiVo-compatible files, right ?

__________________
"It must be swell to be so perfect and odor-free" -- Del Griffith

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

pyTivo users: Try To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.