Open Source Project

[ckewinjones]

Originally Posted by Narflex

Looks like it was built using Microsoft Visual Studio 2005 (at least that's the most recent environment I have installed on my old workstation and that I've now opened the project files with).

If you can open the project files with VS2005, then they were built with VS2005. If they had been built with an earlier version, VS2005 would offer to convert the project files to VS2005 format; if they had been built with a newer version (VS2008 or newer), VS2005 would throw up its hands and refuse to open them.

[pjpjpjpj]

Dang, Vaskill, you sure your name isn't Overkill?
That's an impressive setup!

[wayner]

Originally Posted by Vaskill

Exciting news and I love the interest being shown here.

What I have:

36TB 8 core ESXi 5.5u2 Server with
XP, Vista, Windows 7, Windows 8 and PR Win 10 running; a couple linux installs.
...

Holy Crap!

I don't think the 64 bit firewire is too likely. I would love that as well but people have been asking for that for many years now for all sorts of applications and it doesn't appear likely. Someone has to find Tim M. Moore who adapted the original drivers.

[Fuzzy]

Originally Posted by wayner

Holy Crap!

I don't think the 64 bit firewire is too likely. I would love that as well but people have been asking for that for many years now for all sorts of applications and it doesn't appear likely. Someone has to find Tim M. Moore who adapted the original drivers.

That and fewer and fewer cableco's offer enough channels in the clear to make firewire capture worth it. The few that DO offer a lot of copy freely content, you are likely better off using a CableCard tuner instead.

[wayner]

Originally Posted by Fuzzy

That and fewer and fewer cableco's offer enough channels in the clear to make firewire capture worth it. The few that DO offer a lot of copy freely content, you are likely better off using a CableCard tuner instead.

I have always only used firewire for changing channels, and I am guessing it is the same for Vaskill as I am guessing that he also has Rogers cable. And here in Canada we can't get CableCards. But the good thing is that we can buy cable boxes and an obsolete box with only Component outputs, which is fine for an HD-PVR, can be purchased cheaply on the secondhand market

[Vaskill]

Originally Posted by wayner

I have always only used firewire for changing channels, and I am guessing it is the same for Vaskill as I am guessing that he also has Rogers cable. And here in Canada we can't get CableCards. But the good thing is that we can buy cable boxes and an obsolete box with only Component outputs, which is fine for an HD-PVR, can be purchased cheaply on the secondhand market

Wayner is correct. I stopped using firewire capture as soon as the HD-PVR hit the market.

Of course I have to agree with Fuzzy; I am not holding my breath for FW64bit drivers; but M**H-TV does have some firewire changer features; just can't figure out if it is 64bit or not. I just had to add it as a wish.

So, my current solution is running a super thin Xp32bit VM that is only used for FW; I remotely execute using PSExec from a batch file.

[Narflex]

Originally Posted by Fuzzy

That and fewer and fewer cableco's offer enough channels in the clear to make firewire capture worth it. The few that DO offer a lot of copy freely content, you are likely better off using a CableCard tuner instead.

I use firewire at home on Linux; but only for channel changing.

Originally Posted by wayner

I don't think the 64 bit firewire is too likely. I would love that as well but people have been asking for that for many years now for all sorts of applications and it doesn't appear likely. Someone has to find Tim M. Moore who adapted the original drivers.

Did we ever give out the library for firewire channel changing on Linux? (I think we gave out a binary at least) That'll be part of the open source stuff too; so you can at least compile it for 64 bit Linux.

[Vaskill]

Running FW changing for SA boxes using Linux 64bit OS certainly would be my preferred approach as XP is old and still has a "too large" footprint.

[wayner]

You are the exception but I don't think most of us are going to run a different OS in a VM just to change channels. If there are benefits in going to 64 bit then I will just use my USB-UIRT to change channels.

[Vaskill]

Originally Posted by wayner

You are the exception but I don't think most of us are going to run a different OS in a VM just to change channels. If there are benefits in going to 64 bit then I will just use my USB-UIRT to change channels.

I run SageTV in 64bit since the HD-PVR drivers are much more stable in 64bit and the OS is that much faster with way better memory options.

I want 64bit Win drivers so I can use only one VM for Sage and channel changing.

I can get away with a 64 or 32bit Linux channel changing solution and would still prefer that way over my XP 32bit solution as I could get a very-very small footprint VM and ultimately set it up like an appliance.

This of course might all change as I start to cut the cord from the cable company... we will see how that goes. I could write a book on the evolution of this system. HAHA

[wayner]

I want a way to be ale to run as many as 10 extenders simultaneously. Today you can only use 1GB for the JVM and that only lets you run about 4-5 extenders.

From what I have been lead to believe that can be solved by moving to 64 bit Java. But then that would kill FireWire. However I am worth living with that for the benefit of many extended.

The extender problem may also be solved by running each extender in a separate JVM - but that could run out of memory after a while since you can't put that much memory into 32 bit Windows.

[Fuzzy]

Originally Posted by wayner

I want a way to be ale to run as many as 10 extenders simultaneously. Today you can only use 1GB for the JVM and that only lets you run about 4-5 extenders.

From what I have been lead to believe that can be solved by moving to 64 bit Java. But then that would kill FireWire. However I am worth living with that for the benefit of many extended.

The extender problem may also be solved by running each extender in a separate JVM - but that could run out of memory after a while since you can't put that much memory into 32 bit Windows.

Hopefully we will be able to run multiple JVM 'clients' to drive the miniclients (extenders and placeshifter). Jeff has said that is how they are managing the system on Google Fiber, so hopefully most the work to accomplish that is done. Yes, this would be less memory efficient, but it would allow more extenders - at the worst case, you end up running into using a bunch of swap space - but as I'm guessing most your extenders are not in use simultaneously, I doubt swap in and out will be that impactful.

Or - you could just move away from using firewire. I've always used a USB-UIRT for my channel changing, and have not ever mistuned a station, be it with old 3 Sd cable boxes 8+ years ago, using separate channeled emitters for each, or 3 dish network boxes using a single emitter and multiple IR channels 4 years ago, or my current single HD cable box I use to catch what can't be grabbed with my HDHR Prime.

[traker1001]

Hey friends,We used to use sage alot. It was SUPER. We could use it with the web guide to see channel guides, change channels and set recordings. then from there I could do your standard FF, RW, etc... Guess you could say it was accidentally semi accessible. Couldn't really access any of the wonderful plugins and few other things. But what we could get to worked amazingly. And we always had a place in out heart for it. And we will be coming back to it.

We would be so eternally grateful if when it goes O.S. ANY nice developer may look into the possibility of making an accessible client. For ideas one could look at, Kodi which in itself is awesome because it speaks all the menus and such along with the guide. Before that we could kinda use WMC, which also spoke the guide and many of the menus and such. But hey while Kodi has it's ultimate coolness and WMC is -well- WMC, Comeone we got to admit neither of them our Sage, Which stands in its own coolness.

And before you say "Why would a Visually impaired person want to use a DVR system?" Realize there is A LOT of content out there accessible to us and in fact much of it is beginning to actually include video description in the SAP channel. We also comprehend much of what going on in the content that isn't described.

This would be so amazing. We would even be happy to donate to the cause. We realize that most if any of you have zero personal reason to care about this and believe me we understand that there are probably other things many of you'd much rather use your time for, But it only takes one kind soul to make a major difference to many many folks. If nothing else maybe someone could look at it as a challenge.

Anyways that's our open plea to you wonderful developers.

[Gustovier]

Originally Posted by Fuzzy

Hopefully we will be able to run multiple JVM 'clients' to drive the miniclients (extenders and placeshifter). Jeff has said that is how they are managing the system on Google Fiber, so hopefully most the work to accomplish that is done. Yes, this would be less memory efficient, but it would allow more extenders - at the worst case, you end up running into using a bunch of swap space - but as I'm guessing most your extenders are not in use simultaneously, I doubt swap in and out will be that impactful.

Or - you could just move away from using firewire. I've always used a USB-UIRT for my channel changing, and have not ever mistuned a station, be it with old 3 Sd cable boxes 8+ years ago, using separate channeled emitters for each, or 3 dish network boxes using a single emitter and multiple IR channels 4 years ago, or my current single HD cable box I use to catch what can't be grabbed with my HDHR Prime.

Swapping with Java applications is never good. You will see performance hits especially when garbage collection hits.

[Fuzzy]

Originally Posted by Gustovier

Swapping with Java applications is never good. You will see performance hits especially when garbage collection hits.

Understood - the ideal solution is to just use a 64-bit operating system and more RAM.

[JREkiwi]

Just a couple of references for those that think 64bit JVM is the magic bullet.

here, here and here

Makes the Google Fiber horizontal scaled setup of multiple Java processes look like a better solution

John

[wayner]

I am not an expert at this but some of these problems with 64 bit Java may not be that bad. Today we are limited to 1GB. One downside of 64 bit according to these articles is that apps may take up more memor (maybe as much as 45% more) when you go to 64 bit. There is also a warning about GC taking a long time when you have heaps larger than 12 GB.

From my perspective a 4GB heap size may be big enough to support lots of extenders but not so big as to make GC too slow.

[JREkiwi]

Originally Posted by wayner

From my perspective a 4GB heap size may be big enough to support lots of extenders but not so big as to make GC too slow.

Or you could have each extender with it's own 1.5GB heap in 32 bit without GC affecting multiple extenders.

John

[wayner]

Originally Posted by JREkiwi

Or you could have each extender with it's own 1.5GB heap in 32 bit without GC affecting multiple extenders.

So that would be running on 64 bit Windows, wouldn't it? Since 32 bit Windows can only have 4GB of memory.

I actually have about 8 extenders. In an ideal world they would stay on 100% of the time as it facilitates a faster startup. They wouldn't need 1.5GB ach - about 500MB should suffice.

[Taddeusz]

Originally Posted by wayner

I actually have about 8 extenders. In an ideal world they would stay on 100% of the time as it facilitates a faster startup. They wouldn't need 1.5GB ach - about 500MB should suffice.

I've not had an issue with slow startups since I discovered that using the Home command soft powers on my HD200 rather than the On/Off command which does a full power on.