Explicit versions for ffmpeg and mplayer?

[Tiki]

Originally Posted by Narflex

Yes! Great point. You can easily upgrade from SageTV 7 to the open source version by doing just 2 things.

1. Replace the Sage.jar with the one built from the OS code
2. Put the lucene-core-3.6.0.jar file in your JARs folder

You can download the lucene file from here:

https://github.com/google/sagetv/blo...core-3.6.0.jar

And then click on the RAW button to get it to actually download the file for you.

But is there a new STV file that makes use of any of the new stuff?

[Narflex]

Originally Posted by Tiki

But is there a new STV file that makes use of any of the new stuff?

Most of the stuff in there which would relate to the UI (more imagery, actor details, etc.) is stuff that was on the Google Fiber EPG server...and is not on the SageTV EPG Server..so you won't be able to make much use of it unless someone can create another EPG plugin that can get that kind of data (I'm not sure exactly how, but I figured I'd leave it in there just in case). So there's no newer STV since there wasn't really much other functionality to expose.

[Stu Gare]

Did I read somewhere that v8 ran each extender in its own jvm? I recall something mentioned but I could easily have misunderstood. If they do run in their own jvm is this available in v9 ? Would address a lot of contiguous mem problems when running multiple HD300s concurrently.

[Tiki]

Originally Posted by Narflex

Most of the stuff in there which would relate to the UI (more imagery, actor details, etc.) is stuff that was on the Google Fiber EPG server...and is not on the SageTV EPG Server..so you won't be able to make much use of it unless someone can create another EPG plugin that can get that kind of data (I'm not sure exactly how, but I figured I'd leave it in there just in case). So there's no newer STV since there wasn't really much other functionality to expose.

That's too bad. I think a lot of people were hoping for something new (I know a few people have posted screen shots of the Google Fiber TV ("Sage 8") with new guide layout, new color scheme, etc.

[wayner]

Originally Posted by Stu Gare

Did I read somewhere that v8 ran each extender in its own jvm? I recall something mentioned but I could easily have misunderstood. If they do run in their own jvm is this available in v9 ? Would address a lot of contiguous mem problems when running multiple HD300s concurrently.

See Jeff's response here: http://forums.sagetv.com/forums/showthread.php?t=62321

[scoful]

Originally Posted by Narflex

The ffmpeg/mplayer versions in SageTV have a fair amount of modifications done to them. It's not really a trivial task to upgrade them...some of the changes were bug fixes, some feature adds for metadata output or placeshifting rate control, and some of other various features (like optimizing thumbnail selection).

It would be great to get it back up to speed with the current versions of each...but that is going to be a lot of work for someone with lots of potential for breakage relating to SageTV (it does expect specific formatting of data when using ffmpeg to parse non-mpeg media files or extract their metadata).

As a workaround would it be possible to use both versions - the original variant for placeshifting/metadata scraping and the new version for playback?

[Fuzzy]

You know, looking through the changelog and comparing it to the ffmpeg git, it appears the current sagetv branch of ffmpeg was forked off after the Jan 21, 2008 commit. Should provide a good basis for diff'ing out the changes that were made. It appears that the most major changes were to accept commands via stdin to change the bitrate during the encoding (used for placeshifter's dynamic rate control) and to dump metadata to stderr.

[gdippel]

Originally Posted by Narflex

Yes! Great point. You can easily upgrade from SageTV 7 to the open source version by doing just 2 things.

1. Replace the Sage.jar with the one built from the OS code
2. Put the lucene-core-3.6.0.jar file in your JARs folder

After replacing these two files, will Sage still be able to pull data from the epg server? I have a V7 licensed installation.

[stuckless]

Originally Posted by Fuzzy

You know, looking through the changelog and comparing it to the ffmpeg git, it appears the current sagetv branch of ffmpeg was forked off after the Jan 21, 2008 commit. Should provide a good basis for diff'ing out the changes that were made. It appears that the most major changes were to accept commands via stdin to change the bitrate during the encoding (used for placeshifter's dynamic rate control) and to dump metadata to stderr.

Where I was going with this... when I started the discussion was really to see if we couldn't create a .patch of the differences and then store the patch file. Then we could try upgrading to a new ffmpeg and apply the patch during the build process so that we are always using a vanilla ffmpeg stream, that we patch. The problem of course, is without knowing the very specific build that was used for sagetv, then creating that initial patch will be hard

[Fuzzy]

You should be able to git that date in ffmpeg source, copy over the sage modified source, and it should detect the changes sage made, correct?

[BobPhoenix]

Originally Posted by gdippel

After replacing these two files, will Sage still be able to pull data from the epg server? I have a V7 licensed installation.

Think jm9843 summarized what is needed here from several different posts that Narflex made: http://forums.sagetv.com/forums/show...&postcount=177

[stuckless]

Originally Posted by Fuzzy

You should be able to git that date in ffmpeg source, copy over the sage modified source, and it should detect the changes sage made, correct?

Ideally, yeah. After doing that, you can then run

git status

and see what is modified/added as a result, and then build a patch (requires more steps for that).

But once you have the patch, then you can use git to apply the patch to new version and see what happens

[Fuzzy]

There have been a LOT of changes since 2008...

[stuckless]

Originally Posted by Fuzzy

There have been a LOT of changes since 2008...

Yeah, but initially we are only concerned about the diff/patch from 2008 and that state of the files in SageTV... i would think that would be a much smaller diff.

[Fuzzy]

Originally Posted by stuckless

Yeah, but initially we are only concerned about the diff/patch from 2008 and that state of the files in SageTV... i would think that would be a much smaller diff.

Oh of course, it's not very big at all. I was more stating that the likely hood of said patch working on a current build is probably pretty slim.

[stuckless]

Originally Posted by Fuzzy

Oh of course, it's not very big at all. I was more stating that the likely hood of said patch working on a current build is probably pretty slim.

I agree. It would get nice if it did just work, and git is exceptionally good at patching.

But if it doesn't then I'd to find a release where the patch is valid (or requires minimal effort) and then create a new patch from that release and try to move it forward. This is all very tedious work

Once it is fully patched from the HEAD, I think keeping ffmpeg in sync should be fairly easily...just keep taking recent ffmpeg release, and and patch it (creating a new patch if necessary).

[Fuzzy]

i did find an account online recently of someone adding on on-the-fly bitrate changes to ffmpeg for x264 - said it was only a few lines of code (he's listening to a UDP port to get the changes, while sage writes the changes to stdin) - so at least that part shouldn't be that difficult.

http://stackoverflow.com/questions/2...g-on-bandwidth

[Narflex]

If someone does the whole ffmpeg update...it's probably a good idea to go to the multithreaded version as well (I max out a core on my server at home if I try to placeshifter HDPVR content )