I think you need to add -ar ${asamplerate} to the ffmpegexe.transcode.sameqargs line that pyTivoX writes in the default streambaby.ini. Without that, users won't get streambaby 0.25's fix that makes sure audio is always 44100 or 48000 (the problem I had earlier in the thread with an episode of The Wire).

I think you need to add -ar ${asamplerate} to the ffmpegexe.transcode.sameqargs line that pyTivoX writes in the default streambaby.ini. Without that, users won't get streambaby 0.25's fix that makes sure audio is always 44100 or 48000 (the problem I had earlier in the thread with an episode of The Wire).

I personally haven't, but the latest beta did change some audio processing options that force sample rates to certain values, and that might be causing what you are seeing. Is this a new bug for you in the latest beta?

If it's always been that way, It might just be an issue with ffmpeg and how it's handling your audio. I know some people have complained that when you convert AC-3 audio to aac, sometimes there's a large volume drop (aac and ac-3 normalize to different values). ffmpeg is supposed to have workarounds built-in to handle this, but it's not clear how good those are.

It would help if we knew if it was for ALL types of audio, or just things encoded 5.1, or ac-3 audio, or whatnot. What is the source of your program, and are you using streambaby or pyTivo mode?

This is the first version I have tried, but it looks like this may have been a one time occurrence. I tried some other videos encoded in the same manner and they seem fine. Also, once the video was fully downloaded to the TiVo the audio got louder, so it may have just been due to the fact that I was watching while downloading. I will post again if it happens with another video. Thanks for the quick response and a very helpful piece of software!

I really love this app. Looks great now and streaming works really well. I can't stream any movies purchased on itunes. Any workaround to this? Thanks.

Click to expand...

Movies purchased on itunes are protected with DRM. You are not legally allowed to do anything with them that isn't through itunes (so you can put it on your iphone, or watch it on appleTV or iTunes, but that's it).

Recently apple decided to allow for DRM-free music purchases. Hopefully in the future, they may do the same with their movies. Until then, you may try some 'illegal' options to strip the DRM, but until that happens, pyTivo and streambaby are unable to read your movie files from itunes.

Everything else indicates normal operation. Looks like you downloaded a *cough cough* less-than-legal copy of 24 and whomever made the copy created a slightly 'incorrect' file. But I believe that file should play anyways. You may want to bring this up in the pyTivo thread and see if anyone has any ideas...
If the log is stopping there, then it's possible ffmpeg is crashing on your file (ffmpeg is the thing that converts your file to something that the tivo can use).

It's not just that file. No file will play... I am able to browse to a file and click on it, then I am able to click to start transferring the file to the Tivo, then I'm able to click to start playing the file while it's transferring BUT the problem is the transfer never starts. The Tivo screen claims that the transfer is happening but it never starts to transfer. I get the same result no matter what file I attempt to transfer/play. It's strange that it just doesn't transfer anything.

I've tried many different video files encoded in different formats and I get the same problem. Strange cause it used to work just fine

Your problem. This is an option that was apparently dropped in recent versions of ffmpeg, in favor of a new syntax. We just got a bug report about that on the pyTivo forum, and I just updated my fork to get rid of it.

BTW, your first post did not show this error, nor any other ("... differs from container frame rate" is just a warning).

Your problem. This is an option that was apparently dropped in recent versions of ffmpeg, in favor of a new syntax. We just got a bug report about that on the pyTivo forum, and I just updated my fork to get rid of it.

BTW, your first post did not show this error, nor any other ("... differs from container frame rate" is just a warning).

Click to expand...

I will update the beta tonight to use the fixes in wmcbrine's pyTivo. So if you update the beta tonight (or tomorrow) things should hopefully work again..