April Update - Now No USBUIRT Tuning

[SteveW]

So my Sage server just ran the April 2018 update.... Post update, now my USBUIRT isn't tuning the channels on my Sat receivers. I still see it in the list of USB devices... Anyone else run into this? My HDPVRs are recording - just not from the right channels...




Tnx
-Steve

[SteveW]

Problem seems to have fixed itself, whether due to the rest of the updates, or the 2 or 3 reboots associated with them...

[waynedunham]

Originally Posted by SteveW

Problem seems to have fixed itself, whether due to the rest of the updates, or the 2 or 3 reboots associated with them...

So are you saying that you have USBUIRT working on a Win10 64 bit installation? When I was upgrading my old Windows Home Server machine I really wanted to move to 64 bit, but that would have killed my Firewire tuning of my STBs.
I have a USBUIRT that I originally was using when I had a single STB and no FireWire port. But when I went to 2 STBs (and HD-PVR's naturally) I upgraded to a MOBO with FW ports and the tuning was flawless on both STBs for years.

When I was considering going back to the USBUIRT several things I read said it didn't work with Win8/10 and looking at their website the drivers hadn't been updates in MANY years. So I thought it was a non-starter and went with a 32 bit Windows OS so I could keep my FireWire STB tuning.

If people have working USBUIRT setups with Win10 64 bit I may try to make the move and use my USBUIRT for tuning. Being able to use 64Bit Java would probably help IMMENSELY with all the Java heap overruns I get in the 32 bit Java. Usually at least once a day on my main server and less frequently on my old backup server since it gets used for viewing so little. I just point my SageTV extender to the old backup machine to delete watched shows and make sure it is recording the right things.

[JustFred]

Originally Posted by waynedunham

So are you saying that you have USBUIRT working on a Win10 64 bit installation?

USBUIRT works just fine on Win10 64 bit.

When I was considering going back to the USBUIRT several things I read said it didn't work with Win8/10 and looking at their website the drivers hadn't been updates in MANY years.

Win 7/8/10 all use the same drivers. The fact that they haven't been updated recently doesn't prevent them from working, although installing on Win10 might complain a bit about driver signing (which can be ignored).

Being able to use 64Bit Java would probably help IMMENSELY with all the Java heap overruns I get in the 32 bit Java.

SageTv is still a 32-bit app and requires 32-bit Java. Assuming you continue to use Windows, the greatest gain will be realized by switching from a 32-bit OS to a 64-bit OS.

Remember, any 32-bit version of Windows can only access a max of 3GB of memory. The OS + app(s) must all fit in that 3GB memory space. The Win7/8/10 OS itself eats about 1GB of that, leaving typically only 2GB for all applications. Pretty restrictive.

On the other hand, running a 64-bit version of Win7/8/10 means that any single 32-bit app **itself** can access up to a max of 4GB. While not massive, that's still a pretty big improvement as far as Sage is concerned. Under these conditions, it's possible to bump the Java Heap space up to 1GB.

Personal experience with supporting 4 different Sage systems running on Win7-x64 (with 8GB of memory) has been that (with one exception), the system is very stable and easily runs for 6 months at a time without needing to restart Sage or the OS. Caveat: none of these systems have any Sage extensions installed, which can be fairly heap-hungry.

My single biggest source of Sage instability used to be one system with 2 HD-PVR capture devices and 3 HD-200 extenders. After instituting a nightly power-cycle of the HD-PVRs, that system is also pretty stable now. It runs for months without needing to restart Sage or the OS.

[tvmaster2]

Originally Posted by JustFred

USBUIRT works just fine on Win10 64 bit.

Win 7/8/10 all use the same drivers. The fact that they haven't been updated recently doesn't prevent them from working, although installing on Win10 might complain a bit about driver signing (which can be ignored).


SageTv is still a 32-bit app and requires 32-bit Java. Assuming you continue to use Windows, the greatest gain will be realized by switching from a 32-bit OS to a 64-bit OS.

Remember, any 32-bit version of Windows can only access a max of 3GB of memory. The OS + app(s) must all fit in that 3GB memory space. The Win7/8/10 OS itself eats about 1GB of that, leaving typically only 2GB for all applications. Pretty restrictive.

On the other hand, running a 64-bit version of Win7/8/10 means that any single 32-bit app **itself** can access up to a max of 4GB. While not massive, that's still a pretty big improvement as far as Sage is concerned. Under these conditions, it's possible to bump the Java Heap space up to 1GB.

Personal experience with supporting 4 different Sage systems running on Win7-x64 (with 8GB of memory) has been that (with one exception), the system is very stable and easily runs for 6 months at a time without needing to restart Sage or the OS. Caveat: none of these systems have any Sage extensions installed, which can be fairly heap-hungry.

My single biggest source of Sage instability used to be one system with 2 HD-PVR capture devices and 3 HD-200 extenders. After instituting a nightly power-cycle of the HD-PVRs, that system is also pretty stable now. It runs for months without needing to restart Sage or the OS.

But Firewire tuning is still impossible with any 64bit system, yes?

[JustFred]

Originally Posted by tvmaster2

But Firewire tuning is still impossible with any 64bit system, yes?

Correct. That's the one disadvantage of moving from 32-bit to 64-bit Windows.

[tvmaster2]

Originally Posted by JustFred

Correct. That's the one disadvantage of moving from 32-bit to 64-bit Windows.

More than anything, if I knew how to write code for these kinds of things, I’d update that FireWire, 32bit thing to 64bit. Who was that guy and where did he go? I realize 1394 isn’t used as much these days, but my new, Cox, Cisco set top box still has one, and it still works. And it works very, very well...

[Taddeusz]

Originally Posted by tvmaster2

More than anything, if I knew how to write code for these kinds of things, I’d update that FireWire, 32bit thing to 64bit. Who was that guy and where did he go? I realize 1394 isn’t used as much these days, but my new, Cox, Cisco set top box still has one, and it still works. And it works very, very well...

The deal is the drivers themselves were originally written by, I believe, Panasonic for one of their D-VHS recorders. There were never 64-bit drivers written for those recorders since their use predates 64-bit Windows. Also, since it was a proprietary driver the source code doesn't exist in the wild. So, you'd have to write 64-bit drivers from scratch.

I don't even know where the technical specifications for the messaging protocols live.

[tvmaster2]

Originally Posted by Taddeusz

The deal is the drivers themselves were originally written by, I believe, Panasonic for one of their D-VHS recorders. There were never 64-bit drivers written for those recorders since their use predates 64-bit Windows. Also, since it was a proprietary driver the source code doesn't exist in the wild. So, you'd have to write 64-bit drivers from scratch.

I don't even know where the technical specifications for the messaging protocols live.

I still have a Sony DV Cam with 1394, and yes, had a couple of JVC D-VHS recorders too. Can we ask Panasonic to release the driver code into the wild? Would that help?

[wayner]

Originally Posted by tvmaster2

But Firewire tuning is still impossible with any 64bit system, yes?

No - it works perfectly fine on unRAID Linux which is 64bit and other Linux variations as well.

[wayner]

Originally Posted by tvmaster2

More than anything, if I knew how to write code for these kinds of things, I’d update that FireWire, 32bit thing to 64bit. Who was that guy and where did he go? I realize 1394 isn’t used as much these days, but my new, Cox, Cisco set top box still has one, and it still works. And it works very, very well...

The guy who got this all going was Tim M Moore - although his web page has disappeared.

[waynedunham]

Originally Posted by wayner

The guy who got this all going was Tim M Moore - although his web page has disappeared.

From everything I've read over the years searching in vain for a 64bit Windows Firewire tuning capability it was in fact those drivers which are 32 bit. As far as I know they never released any source code, just the driver which Tim Moore used for our FW turning.

If Windows SageTV can't use 64bit at all then moving and setting up USBUIRT would be moot for me. I'm not really having any performance issues using 32bit Windows, it is just the constant Java Heap overruns where I have problems. Every time my main machine (which has more lineups) does an EPG update if fires off the Java Heap warning message (set at 90% and my Java Heap is maxxed out).
Weird thing that happens just lately is that when this happens after an EPG update my recordings listings won't honor my settings. The "current recordings" aren't supposed to show archived recordings, but do. Once I restart the server and clear the Java heap problem they once again do not show under current recordings.

There is another very short thread elsewhere about getting 64bit Java to work with SageTV Windows version. Narflex said something along the lines of as far as he know the code should work with 64 bit Java and suspected one or some of the compiled DLL(s) might be where the problem lies. Sure would be nice to get it working with 64 bit Java.

[Taddeusz]

Originally Posted by waynedunham

From everything I've read over the years searching in vain for a 64bit Windows Firewire tuning capability it was in fact those drivers which are 32 bit. As far as I know they never released any source code, just the driver which Tim Moore used for our FW turning.

If Windows SageTV can't use 64bit at all then moving and setting up USBUIRT would be moot for me. I'm not really having any performance issues using 32bit Windows, it is just the constant Java Heap overruns where I have problems. Every time my main machine (which has more lineups) does an EPG update if fires off the Java Heap warning message (set at 90% and my Java Heap is maxxed out).
Weird thing that happens just lately is that when this happens after an EPG update my recordings listings won't honor my settings. The "current recordings" aren't supposed to show archived recordings, but do. Once I restart the server and clear the Java heap problem they once again do not show under current recordings.

There is another very short thread elsewhere about getting 64bit Java to work with SageTV Windows version. Narflex said something along the lines of as far as he know the code should work with 64 bit Java and suspected one or some of the compiled DLL(s) might be where the problem lies. Sure would be nice to get it working with 64 bit Java.

There was someone who was working on porting the Windows SageTV to 64-bit. I'm not sure how far along that's gotten. I'm sure it's just the native code that's the problem. For me all that is now moot as I've moved to using unRAID and run the Linux 64-bit version of SageTV from Docker. While I'm sure it's not the perfect solution for everyone it works quite well in my environment. I'm very pleased with the result. I just wish SageTV supported more modern technologies like using Intel Quick Sync for video transcoding.

[tvmaster2]

Originally Posted by Taddeusz

There was someone who was working on porting the Windows SageTV to 64-bit. I'm not sure how far along that's gotten. I'm sure it's just the native code that's the problem. For me all that is now moot as I've moved to using unRAID and run the Linux 64-bit version of SageTV from Docker. While I'm sure it's not the perfect solution for everyone it works quite well in my environment. I'm very pleased with the result. I just wish SageTV supported more modern technologies like using Intel Quick Sync for video transcoding.

I guess Narflex and gang have given up on those kinds of advancements, especially since it’s open source now?

[Taddeusz]

Originally Posted by tvmaster2

I guess Narflex and gang have given up on those kinds of advancements, especially since it’s open source now?

I think Narflex would approve any changes like that. Unless it's a more serious bug or something that affects him personally he's not going to be doing any work on it. He's more of a moderator now.

The problem is finding someone with the knowledge and time to do the work. One of the big problems with this project is the lack of active developers with institutional knowledge. I think there are a few devs that have gained enough knowledge about little bits and pieces of the code to make necessary small changes. Narflex is really the only one that has that kind of knowledge but he's not really active.

People can keep using SageTV as-is but unfortunately I don't think things in the core are going to change much, if at all. With modern products like Plex making inroads into DVR territory SageTV doesn't look as good as it once did. Plex has, IMHO, a nicer interface built on modern web technologies and also supports hardware transcoding using Quick Sync.

SageTV's web interface is pretty hard on the eyes and is built using old-school Tomcat server-side dynamic page building. Far from the efficient REST or GraphQL used today where the client builds its own interface based on data from the API server.

Anyway, sorry, I'm rambling now. Got myself on a soapbox.

[wayner]

Originally Posted by Taddeusz

People can keep using SageTV as-is but unfortunately I don't think things in the core are going to change much, if at all. With modern products like Plex making inroads into DVR territory SageTV doesn't look as good as it once did. Plex has, IMHO, a nicer interface built on modern web technologies and also supports hardware transcoding using Quick Sync.

Sage still has some other advantages, like supporting comskip files, easily skipping over sections of a file, plus all of the intelligence around not recording shows that have been watched or recorded in the past.

[Taddeusz]

Originally Posted by wayner

Sage still has some other advantages, like supporting comskip files, easily skipping over sections of a file, plus all of the intelligence around not recording shows that have been watched or recorded in the past.

I will agree with you on comskip. While Plex does now integrate comskip they use it to permanently remove those sections of recordings rather than just detecting where commercials might be. If this works it's not a problem but it can become a problem when you get a lot of false positives where it removes stuff that is not commercial. TV networks have ways they screw up commercial detection that make this problematic.

The latest version of the Plex UI actually includes chapter support. So it may not be that difficult to make use of that. They may be on the road to doing not-destructive commercial skipping.

I've not been able to dig that far into Plex's DVR due to it still being kind of buggy but they already have a pretty good system of knowing what you have and haven't watched. I have done tests with it and my two HDHR's but I keep getting partial recordings where it just stops getting data and then Plex crashing between sequential scheduled recordings. I keep trying it though.