I noticed the uppercase V for the file name. But it didn't do anything for me.

I actually captured the HTTP string sent to the PC's port 80 by Tivo after I add PC's IP via "Manually add a server...":

/TiVoConnect?Command=QueryContainer&Container=&#37;2F&Format=text%2Fxml HTTP GET

I am not HTTP expert. But this is certainly not the HTTP for getting the file TiVoConnect. I don't know if the query command can be understood by any web server or only by some Tivo-aware server (or MHO, pyTivo?) so that the file TiVoConnect can be sent back to Tivo as the response?

Click to expand...

I'd try another web server-- Most standard web servers just strip off the part after the '?' and serve up that file (which is what we are looking for). I just tried the web server you posted a link to earlier (as well as looking at the source) and it doesn't strip out the stuff after the '?' so it is looking for the wrong file.

Edit: The above is a bit of an over-simplification, but in general it describes the expected reaction of a typical web server to a URL with query parameters pointing to a file in a real file system.

I have recently began to assemble the "plumbing" to attach a video library to my Tivo. I recently built a windows home server and that is the platform I wish to create the video library on. I installed pyTivo and StreamBaby so I can access videos that can be stored on the server from the Tivo.

Is there anyway to "dress-up" the StreamBaby menus with Metadata from the WHS? Seems there is a good source for Metadata to attach to movies on the internet. I looked at MyMovies and it collects a lot of the metadata from Windows Media Center. It would be nice if that could be available through a SteamBaby access. I do not know if Tivo renders their menus using CML stored in the Video folders -

I have not searched too widely yet. I am still very much in the creating plumbing mode but I am not far from creating the library mode so it is a good time to ask.

Click to expand...

Streambaby supports pyTivo style metadata files (as well as straight HTML, TiVo formal XML files, plus others). pyTivo style metadata files are probably the way to go as there is a lot of documention around the web as well as utiltiies for creating/manipulating them. (I'd point them out, but I don't know off the top of my head where the info is...)

Streambaby supports an additional pyTivo tag "Image : " which can point to an image to use when displaying metadata for the movie.

Streambaby supports pyTivo style metadata files (as well as straight HTML, TiVo formal XML files, plus others). pyTivo style metadata files are probably the way to go as there is a lot of documention around the web as well as utiltiies for creating/manipulating them. (I'd point them out, but I don't know off the top of my head where the info is...)

Streambaby supports an additional pyTivo tag "Image : " which can point to an image to use when displaying metadata for the movie.

Click to expand...

Thanx - a starting point.

is there any integration of the metadata collected by myMovie? I installed this which installs an SQL DB and when I put a DVD in the drive - it collects movie image and metadata from the Internet and stores it in the database.

I'd try another web server-- Most standard web servers just strip off the part after the '?' and serve up that file (which is what we are looking for). I just tried the web server you posted a link to earlier (as well as looking at the source) and it doesn't strip out the stuff after the '?' so it is looking for the wrong file.

Edit: The above is a bit of an over-simplification, but in general it describes the expected reaction of a typical web server to a URL with query parameters pointing to a file in a real file system.

Click to expand...

I installed Apache for Windows and it works. Thanks! This is a neat trick. The only issue is that I have to use static IP for PC. Is there a way for streambaby to utilize the tivobeacon for broadcast/discovery? It seems that quite a few network devices lack Bonjour support. The option to run without Bonjour will be a good added feature for streambaby.

I now can play avi, mp4, rmvb smoothly although I don't know which ones use transcoding and which ones are streamed directly. But streambay often sends warnings about not being able to find some resources, such as "resource 5362 not found". The playback of RMVB also can not be resumed once it is in the trick mode (e.g. FF). Nonetheless, streambaby is a great HME app. Thanks again.

Streambaby supports pyTivo style metadata files (as well as straight HTML, TiVo formal XML files, plus others). pyTivo style metadata files are probably the way to go as there is a lot of documention around the web as well as utiltiies for creating/manipulating them. (I'd point them out, but I don't know off the top of my head where the info is...)

Streambaby supports an additional pyTivo tag "Image : " which can point to an image to use when displaying metadata for the movie.

Click to expand...

KearyGriffin, are there plans to allow for multiple endofline characters (ie: Unix, Win or Mac EOLs)? I have some people who are alpha-testing my Tago software (that writes tags automatically for .txt files and .mp4-style ATOMs) that are complaining that the minute (on windows or Mac) they edit these .txt files in generic text editors, neither pyTivo nor Streambaby interpret these files correctly. I fixed my issue by forcing UNIX endoflines when writing the file -- and telling users not to edit the files outside of Tago, but it seems to me rather closed-minded that both pyTiVo and Streambaby which, due to their python and Java nature can be run cross-platform, locks its users into writing EOLs in Unix format. isn't this an issue that needs to be taken care of?

I am gonna copy this to wmcbrine too (as I think pyTivo needs to be changed as well)

I get them on many files -- and most of the time the problem goes away for awhile if i EITHER transcode them to a different "quality" (which means it is a java issue...as this forces ffmpeg to read the file) or restart the tivoHD.

I have several hand-encoded files (from flv to x264) that this happens too...but once it happens, any files I have EVER encoded that streambaby does NOT transcode will give that error.

On a different machine (than the one I mentioned previously in this thread) I made use of the "/Users/<user>/Library/Application Support/pyTivoX/streambaby-user.ini" file and did the following on a "iMac 7,1" aluminum:

It massively sped up the processing (and therefore transmission) of .mkv files and other files that ffmpeg are involved in transcoding. I was wondering why "-threads 2" is the default on the pyTivoX installation (and I am assuming the StreamBaby default installation) when even on a Mac Mini (at least *my* Mini) that does not peg the processor. This ("-threads 4") at least goes 160% in the "Activity Monitor"... "-threads 2" only goes 60-90%.

Also, when I use MacPorts under Snow Leopard and compile ffmpeg with the following options:

Okay, I need some streambaby assistance. I am running a Windows Home Server where all my video files are located. I have pyTivo installed on the server itself and it automatically runs and serves up my video to my 2 S3s. I have played around with streambaby a little, but the streaming seems choppy with it running on a wireless laptop. Should streambaby instead be installed directly on the server, like I have done with pyTivo to ensure the smoothest streaming? If so, is there a way to make streambaby run automatically at startup (like if the server ever needs a restart)? I am looking for seamless functionality for the spousal unit. If that is not the correct way of doing things, can someone steer me in the right direction?

Sorry about the noob questions, sometimes I need to be talked through like I'm 8.

I'm not seeing that here. Both LF and CR/LF endings work for me in pyTivo, under both Linux and Windows. I haven't tried old Mac style (CR-only); I wouldn't be surprised if that one failed.

I wonder if your complaining Windows users are saving as RTF or something? Windows can get very creative in how it mangles things.

I tested with Python 2.6.2 in Ubuntu and 2.5.1 in Win XP. I doubt this has changed with new Python versions. pyTivo simply relies on Python to split the file into lines (i.e., "for line in file(metadata):"), and on .strip() to remove the line endings. The metadata files are opened in text mode, but it makes no difference if I change that to open them in binary mode.

It massively sped up the processing (and therefore transmission) of .mkv files and other files that ffmpeg are involved in transcoding. I was wondering why "-threads 2" is the default on the pyTivoX installation (and I am assuming the StreamBaby default installation) when even on a Mac Mini (at least *my* Mini) that does not peg the processor. This ("-threads 4") at least goes 160% in the "Activity Monitor"... "-threads 2" only goes 60-90%.

Also, when I use MacPorts under Snow Leopard and compile ffmpeg with the following options:

and then add the following to the "/Users/<user>/Library/Application Support/pyTivoX/streambaby-user.ini" file:

Code:

ffmpeg.path=/opt/local/bin/ffmpeg

the speed bump is enormous--even on a Mini over just increasing the "-threads 2" option! Is there a reason to use the libraries and binaries that ship with applications such as pyTivoX?

Click to expand...

ffmpeg docs generally say to use threads = number of processors. On my older hardware I tended to only use 2 for dual core machines, bumping it up to 4 didn't help and in some cases hurt. I haven't tested with greater than 4 on my Q6600, but I'll give it a shot and see later. The point is it will vary depending on your hardware...

As for the Snow Leopard MacPorts compile, older Apple compilers created ffmpeg binaries that would crash when the full Intel optimizations were enabled, so for a while MacPorts would disable Intel optimizations for ffmpeg. I think Apple finally fixed the compiler problem with Xcode 3.0 or 3.1 and I guess MacPorts finally caught up so what you are seeing is an ffmpeg with full Intel optimizations enabled AND the additional optimization improvements moving from Xcode 3.1 to 3.2. Not sure whether the 32 vs 64 bit has anything to do with it. Haven't looked at the MacPorts stuff in Snow Leopard yet.

I'm not seeing that here. Both LF and CR/LF endings work for me in pyTivo, under both Linux and Windows. I haven't tried old Mac style (CR-only); I wouldn't be surprised if that one failed.

I wonder if your complaining Windows users are saving as RTF or something? Windows can get very creative in how it mangles things.

I tested with Python 2.6.2 in Ubuntu and 2.5.1 in Win XP. I doubt this has changed with new Python versions. pyTivo simply relies on Python to split the file into lines (i.e., "for line in file(metadata):"), and on .strip() to remove the line endings. The metadata files are opened in text mode, but it makes no difference if I change that to open them in binary mode.

Click to expand...

In testing I just confirmed that Mac EOL (CR) does mess up the pyTivo interpretation of the meta files. I will check with my users to see but they said they were using notepad.exe and I did not think notepad (mac user here--so am not sure) saved as RTF.

In testing I just confirmed that Mac EOL (CR) does mess up the pyTivo interpretation of the meta files. I will check with my users to see but they said they were using notepad.exe and I did not think notepad (mac user here--so am not sure) saved as RTF.

Click to expand...

I just tested streambaby with CR, CR/LF, LF and they all seemed to work for me (at least under Linux).

The thing you need to be careful of with Notepad.exe is that it unfortunately likes to add a UTF-8 BOM marker to the beginning of text files. At least for Java, it wasn't handled automatically and at some point I had to add a bunch of code to deal with it.

As for the Snow Leopard MacPorts compile, older Apple compilers created ffmpeg binaries that would crash when the full Intel optimizations were enabled, so for a while MacPorts would disable Intel optimizations for ffmpeg. I think Apple finally fixed the compiler problem with Xcode 3.0 or 3.1 and I guess MacPorts finally caught up so what you are seeing is an ffmpeg with full Intel optimizations enabled AND the additional optimization improvements moving from Xcode 3.1 to 3.2. Not sure whether the 32 vs 64 bit has anything to do with it. Haven't looked at the MacPorts stuff in Snow Leopard yet.

Click to expand...

In examining the resulting ffmpeg with x264 I am seeing all optimizations including the following during an encode. This would indicate the speed improvements seen with a pyTivo/StreamBaby transcode:

That is a 300% improvement on firstpass and a 250% improvement on 2nd pass. (The -threads 0 argument just lets x264 use as many threads as it thinks it needs). It ends up using 180% processing time so both cores ARE in use. For those that say: "Hey ... of course it is faster -- he turned of bpyramid", I explicitely turn off bpyramid (-flags2 -bpyramid ) cos using mb-tree -- which is the default now -- is much better (in my estimation) and that default option turns off bpyramid anyway. Doing it on the command line simply reminds me it is being done.

Again, this is simply encoding -- not transcoding.. but the math should be roughly the same. This is also 64bit build (actually it is a universal build across the board).

I just tested streambaby with CR, CR/LF, LF and they all seemed to work for me (at least under Linux).

The thing you need to be careful of with Notepad.exe is that it unfortunately likes to add a UTF-8 BOM marker to the beginning of text files. At least for Java, it wasn't handled automatically and at some point I had to add a bunch of code to deal with it.

Click to expand...

What I got when I saved the metafiles using Mac CR and served them up using StreamBaby on an "iMac 7,1" using pyTivo was:

I was wondering why "-threads 2" is the default on the pyTivoX installation (and I am assuming the StreamBaby default installation) when even on a Mac Mini (at least *my* Mini) that does not peg the processor. This ("-threads 4") at least goes 160% in the "Activity Monitor"... "-threads 2" only goes 60-90%.

Click to expand...

I actually think the Streambaby default is ffmpeg.threads=1. It's a relatively recent addition to streambaby and I didn't want to change the default behaviour.

I tried -threads 0 which I thought was "auto", but at a minimum it crashes the stock Ubuntu ffmpeg, so that was out.

I probably won't do anything about this except leave it as it is and let people change their INI to set the thread parameter as they want. (Except maybe if ffmpeg does end up with an "auto" parameter, use it)

And just as a side note, at least for streambaby when you are doing your benchmarks, you should be transcoding/encoding to MPEG-2 (not h.264).

I would hazard to guess they're using Notepad, which can really mangle line breaks if the file doesn't originally have the only type of line break Notepad understands (CR-LF if I remember correctly - whatever the Windows standard is). Since the source config wasn't originally built on Windows, probably when they "correct" it they're getting a sequence of 3 or 4 different breaks on each line.

FWIW when I was a Windows user I found Textpad to be a much superior text editor. It's shareware, but back in the day it was still usable in its free version (although I found it useful enough that I bought a license).

On the Mac I've used both the free TextWrangler and it's paid sibling BBedit - both work just fine with streambaby and pyTivo config files. They're smart enough to recognize the type of line endings being used by the file, and sticking with that pattern when you edit it.

And just as a side note, at least for streambaby when you are doing your benchmarks, you should be transcoding/encoding to MPEG-2 (not h.264).

Click to expand...

What? I thought streambaby encoded to MP4...not Mpeg2 when it had to transcode. That, I thought, is why mp4's were sent unchanged to the tivo? Is that a choice cos it is faster to encode to mpeg2 than mp4 or is it a requirement?