Sage on life support

[will]

Originally Posted by tvmaster2

well, for one, little things - like someone updating the 1394 channel change plugin. I know they didn't do it originally, but the fellow who did is long gone, and it would be great to have a 64bit version for Windows.

I wouldn't hold my breath on that one. Writing drivers, low-level code, is hard and it is triple hard when the information you need to write the driver isn't publicly available. I can't recall completely, but I think Tim somehow got the 32bit firewire drivers, I don't think he wrote them himself but I could be wrong, I think those drivers are 8 or 10 years old.

Originally Posted by tvmaster2

Also, updating things like the Online / More Online Services - lots of outdated dead stuff there.
as I said, little things

That's very doable but we would have to identify the login-free video sources to update with.

[hoosierengineer]

Honestly, I think the biggest reluctance to adopt Sage is the difficulty in getting it to work completely, and the lack of documentation. I just spent a few more days on and off trying to get another client working. If you don't know things like needing to install Sage 7 before Sage 9, downloading LAV filters, choosing the right setup options, for the average non-software Joe, it is practically impossible to get it working to its full capabilities. Some folks liked the challenge/reward of just getting each feature to function, but I believe it is difficult to get new interest going as these issues persist.

Right now, I am staring at the initial sequence of a DVD playing on my computer, wondering how to get the movie to play, without grabbing a remote control. Clicking the mouse over the PLAY graphic does nothing.

[hoosierengineer]

Oh, and my wife subscribes to NetFlix. I don't believe we can use Sage to access the programming. When I first started using Sage, it was the only program that would work with digital television tuners, and was very cool. Now, if I do a web search for "watch TV on computer", I don't believe Sage comes up as an early hit.

[hoosierengineer]

One last criticism, broadcast television shows seem to jump/hang briefly (fraction of a second) - don't know if this is the broadcaster, interface to Sage, or problem with the renderer.

Sage is an absolutely terrific value. I would gladly pay for an updated, modern version. I tried Plex and a couple of others, but they don't have the features Sage has, and they are a decade newer. The Sage authors have every reason to be proud of their work. It has been stable and reliable (something I can't say for the operating system it runs on - although it looks like Microsoft recently fixed a problem that has been haunting Sage FF/RW for years).

[jusjoken]

Originally Posted by hoosierengineer

If you don't know things like needing to install Sage 7 before Sage

This has not been a requirement for a long time...but perhaps that builds your case for lack of documentation.

k

[Taddeusz]

I’m not entirely sure if this isn’t an Unraid problem but I’ve noticed that when SageTV is waiting for a drive to spin up it freezes until the drive becomes ready. This is particularly annoying when you’re watching something. It seems that SageTV doesn’t run file access code on a separate thread so it blocks the main thread when it’s waiting for drives to become active.

[trk2]

Originally Posted by Taddeusz

I’m not entirely sure if this isn’t an Unraid problem but I’ve noticed that when SageTV is waiting for a drive to spin up it freezes until the drive becomes ready. This is particularly annoying when you’re watching something. It seems that SageTV doesn’t run file access code on a separate thread so it blocks the main thread when it’s waiting for drives to become active.

This has been a long standing problem. My workaround is to set the recurring scan for imported media to something less than the drive sleep time. This will keep all the drives active while Sage is in use and still allow the computer to sleep while Sage is inactive.

[stuckless]

Originally Posted by Taddeusz

I’m not entirely sure if this isn’t an Unraid problem but I’ve noticed that when SageTV is waiting for a drive to spin up it freezes until the drive becomes ready. This is particularly annoying when you’re watching something. It seems that SageTV doesn’t run file access code on a separate thread so it blocks the main thread when it’s waiting for drives to become active.

I would classify this as an unRAID configuration issue. Even if sagetv did spin up a number of theads to do nothing but just touch the filesystem every second (which seems really bad in my mind), when you are running on something like unRAID, it has no idea that your "volume" spans multiple physical drives, and we are not going to write unRAID specific code in to the product to determine what physical drives maps into a volume so we can keep them spinning Configure you unRAID server to not put the drives into sleep mode.

[Taddeusz]

Originally Posted by stuckless

I would classify this as an unRAID configuration issue. Even if sagetv did spin up a number of theads to do nothing but just touch the filesystem every second (which seems really bad in my mind), when you are running on something like unRAID, it has no idea that your "volume" spans multiple physical drives, and we are not going to write unRAID specific code in to the product to determine what physical drives maps into a volume so we can keep them spinning Configure you unRAID server to not put the drives into sleep mode.

This isn't just an Unraid problem though. This probably does affect Windows also. Putting drives in standby is the default for Windows. I'm not going to get into the argument about how much power spinning drives actually use.

From a programming point of view though, we shouldn't expect to need special configuration for our software to work as expected without unduly impacting the user. Threading naturally asynchronous processing makes sense to keep the main thread from locking. Especially when you're dealing with such a user focused application. It's even more important due to the fact that the media extenders depend on the server for their UI.

IMHO, no task that could possibly take long enough to impact the user should be allowed to lock the main thread or any thread that could impact user experience. If we as programmers always expect the best circumstances than our programs will always fail under the worst.

[stuckless]

Originally Posted by Taddeusz

This isn't just an Unraid problem though. This probably does affect Windows also. Putting drives in standby is the default for Windows. I'm not going to get into the argument about how much power spinning drives actually use.

From a programming point of view though, we shouldn't expect to need special configuration for our software to work as expected without unduly impacting the user. Threading naturally asynchronous processing makes sense to keep the main thread from locking. Especially when you're dealing with such a user focused application. It's even more important due to the fact that the media extenders depend on the server for their UI.

IMHO, no task that could possibly take long enough to impact the user should be allowed to lock the main thread or any thread that could impact user experience. If we as programmers always expect the best circumstances than our programs will always fail under the worst.

This is not a question of how efficient threading is?? This is about the architecture of the concept of a "volume". If you are watching a video, being served from a volume that is made up of several physical drives, and then the video stops, and the UI needs to reload its images from the same volume, but, that data is on a drive that is physically put to sleep, it has to wake it up, and the UI will block until the drive becomes available. The problem is that sagetv doesn't know you are using a multi-disk volume. So what does it do, just touch every file that it knows it about, always, to ensure that it never goes to sleep?? (Is that really any different or better than just simply telling the drives to never sleep)

[Taddeusz]

Originally Posted by stuckless

This is not a question of how efficient threading is?? This is about the architecture of the concept of a "volume". If you are watching a video, being served from a volume that is made up of several physical drives, and then the video stops, and the UI needs to reload its images from the same volume, but, that data is on a drive that is physically put to sleep, it has to wake it up, and the UI will block until the drive becomes available. The problem is that sagetv doesn't know you are using a multi-disk volume. So what does it do, just touch every file that it knows it about, always, to ensure that it never goes to sleep?? (Is that really any different or better than just simply telling the drives to never sleep)

I think we're talking about different but maybe similar things.

If you're talking about scrolling through your list of recordings, then no, loading images should not keep you from scrolling further down the list if it's waiting for drives to become available. Which actually does happen quite frequently and is irritating as hell. I shouldn't need to schedule my drives to spin up just to keep things "usable". IMHO, that's just lazy programming. Modern web browsers and web sites are even written to load images asynchronously because psychologically the immediacy of the interface is more important than how quickly the images and all the other javascript packages load. You shouldn't have to wait for all the images to load just so it looks "perfect" when the user sees it. That's why you put the javascript at the bottom of the HTML.

In my case this isn't even the issue I was talking about. We were in the middle of watching a show and the video froze several times while drives were spinning up for doing something in the background.

I actually have my fanart along with my Docker appdata on my cache SSD. Which is of course never put in standby. I actually point my fanart directly to "/mnt/cache" rather than going through the shfs "/mnt/user" volume. The only thing related to SageTV that is on the array is the media itself. What I'm really talking about is stuff that is being done in the background that should have zero bearing on what is going on in the UI (e.g. simply watching a show).

It's these little details that make SageTV frustrating to use on even a relatively modern system. My "meager" i5 3470 shouldn't have these sorts of issues.

[hoosierengineer]

Quick back to my rants---

I also have SageTV client running on a Windows 7 machine. This morning, I discovered the mouse works fine with Sage on it (I can select PLAY, it highlights when I hover over it). What's different about Windows 10? I just tried to update the mouse driver, it claims I have the latest, but I doubt that is the problem.

[hoosierengineer]

OK, got it working. Need to set the DVD Video Renderer to VMR 9. Gotta add that to my SageTV notes files.

[stuckless]

Originally Posted by Taddeusz

I think we're talking about different but maybe similar things.

If you're talking about scrolling through your list of recordings, then no, loading images should not keep you from scrolling further down the list if it's waiting for drives to become available. Which actually does happen quite frequently and is irritating as hell. I shouldn't need to schedule my drives to spin up just to keep things "usable". IMHO, that's just lazy programming. Modern web browsers and web sites are even written to load images asynchronously because psychologically the immediacy of the interface is more important than how quickly the images and all the other javascript packages load. You shouldn't have to wait for all the images to load just so it looks "perfect" when the user sees it. That's why you put the javascript at the bottom of the HTML.

In my case this isn't even the issue I was talking about. We were in the middle of watching a show and the video froze several times while drives were spinning up for doing something in the background.

I actually have my fanart along with my Docker appdata on my cache SSD. Which is of course never put in standby. I actually point my fanart directly to "/mnt/cache" rather than going through the shfs "/mnt/user" volume. The only thing related to SageTV that is on the array is the media itself. What I'm really talking about is stuff that is being done in the background that should have zero bearing on what is going on in the UI (e.g. simply watching a show).

It's these little details that make SageTV frustrating to use on even a relatively modern system. My "meager" i5 3470 shouldn't have these sorts of issues.

Yeah, I had the issue, in the past where if I watched a 2hr movie, and then went back to the main UI, I would get a spinning circle for about 30 seconds as my drives would spin up (because sagetv would be accessing it's image artifacts to rebuild the UI -- nothing to do with fanart).

Your problem seems like a system configuration issue. I've never seen an issue where the video would freeze simply because another background process would start to access a drive that was sleeping. I would actually think this might be a hardware issue, or even something in the bios. Not sure what sagetv could do to fix this particular problem (which has been my position since the first comment). Sure, sagetv could keep hammering all the drives, preventing them from sleeping, but really, is that something that sagetv should be doing?

[Taddeusz]

Originally Posted by stuckless

Yeah, I had the issue, in the past where if I watched a 2hr movie, and then went back to the main UI, I would get a spinning circle for about 30 seconds as my drives would spin up (because sagetv would be accessing it's image artifacts to rebuild the UI -- nothing to do with fanart).

Your problem seems like a system configuration issue. I've never seen an issue where the video would freeze simply because another background process would start to access a drive that was sleeping. I would actually think this might be a hardware issue, or even something in the bios. Not sure what sagetv could do to fix this particular problem (which has been my position since the first comment). Sure, sagetv could keep hammering all the drives, preventing them from sleeping, but really, is that something that sagetv should be doing?

It's possible but I honesty don't think hardware or BIOS is the issue. I've been across two different platforms and different HBA's. Originally this was a dual quad core Xeon 5430. The i5 3470 is actually slightly faster than the two Core 2 era Xeon's.

My hardware is essentially completely different now from when I started running Unraid. My primary controller is now a Dell H310 cross-flashed to the 9211 IT firmware. Prior to Saturday morning it was a cross-flashed IBM m1015. So basically the same card. My cache and parity drives are running off the two 6Gb motherboard ports while the rest of the 8 array drives are on the SAS card.

In a couple weeks I'm going to be upgrading to a six core i5 8400 or 8500. I also plan on eventually upgrading my cache drive to a 500GB NVME. I'd like to go for 1TB but the price difference is pretty high.

I have had issues with NZBGet clogging things but since I changed my Docker containers to point directly to the cache drive rather than going through the shfs user volume that seems to have cleared up.

[trk2]

Originally Posted by stuckless

I've never seen an issue where the video would freeze simply because another background process would start to access a drive that was sleeping.

This will manifest in Sage during playback with the video freezing for several seconds than fast forwarding to catch up. There are numerous threads about this issue and I'm sure you have probably helped to resolve some of them. This can be caused by sleeping drives. I'm not sure if it's from a background media scan or from a recording starting to a sleeping drive while playback is from a separate drive.