Seriously?

Help and support for HDHomeRun DVR and HDHomeRun software for Windows 10, Mac, Android, XBox, etc.
rpcameron
Posts: 893
Joined: Fri Mar 25, 2016 9:55 am

Re: Seriously?

Post by rpcameron » Fri Jan 03, 2020 11:14 am

nateb wrote:
Fri Jan 03, 2020 10:35 am
rpcameron wrote:
Fri Jan 03, 2020 2:59 am

It's this attitude that keeps SD's software from being a viable alternative. They're well aware of the shortcomings of their software, they know it's been unusable, they continue to promote it, and they refuse to fix it.

Their move to a remote-hosted, React-based UI is just further proof of this user-hostile approach.
Neat. I didn't know "it's something we need to figure out" translates to "we refuse to fix it" in whatever language you speak. I'll have to keep that in mind in the future.
Re-writing and refactoring the UI would have been the optimal time to "figure out" the UX errors and shortcomings. Instead, the problems were brought forward into the new codebase where they continue to plague the software. Knowing there was a problem with the first version of the software, and the bringing that same problem forward to the next version of the software, I feel is accurately portrayed with "refused to fix".

In this manner, "something we need to figure out" came out as "something we didn't care enough to address when re-writing our software", which since it was a problem before, and is a problem still, translates as "refused to fix".

nateb
Silicondust
Posts: 1167
Joined: Mon Aug 06, 2018 3:22 pm
Device ID: 1051C73D, 10759F29

Re: Seriously?

Post by nateb » Fri Jan 03, 2020 11:25 am

Bobstr wrote:
Fri Jan 03, 2020 11:13 am
Having to get out of discover and the show/game listing, then open slice and find the $&*U*@ channel in slice after you were just looking at it in Discover is a very backward, too many step process.
No arguments here. To fix this, we'll really need an updated design for that page. Believe it or not, a few have already been suggested. It's just a matter of getting those ideas in development.

StraightThruTheHeart
Posts: 43
Joined: Mon Jul 29, 2019 1:37 pm

Re: Seriously?

Post by StraightThruTheHeart » Fri Jan 03, 2020 1:52 pm

[posts from this account are not displayed]

Bobstr
Posts: 160
Joined: Mon Oct 22, 2012 2:07 pm
Device ID: 131CCFEA, 1314A87C
Location: Seattle area

Re: Seriously?

Post by Bobstr » Fri Jan 03, 2020 1:55 pm

nateb wrote:
Fri Jan 03, 2020 11:25 am
Bobstr wrote:
Fri Jan 03, 2020 11:13 am
Having to get out of discover and the show/game listing, then open slice and find the $&*U*@ channel in slice after you were just looking at it in Discover is a very backward, too many step process.
No arguments here. To fix this, we'll really need an updated design for that page. Believe it or not, a few have already been suggested. It's just a matter of getting those ideas in development.
:D

rykr
Posts: 346
Joined: Sat Oct 31, 2015 5:09 am

Re: Seriously?

Post by rykr » Fri Jan 03, 2020 4:29 pm

rpcameron wrote:
Fri Jan 03, 2020 11:14 am
nateb wrote:
Fri Jan 03, 2020 10:35 am
rpcameron wrote:
Fri Jan 03, 2020 2:59 am

It's this attitude that keeps SD's software from being a viable alternative. They're well aware of the shortcomings of their software, they know it's been unusable, they continue to promote it, and they refuse to fix it.

Their move to a remote-hosted, React-based UI is just further proof of this user-hostile approach.
Neat. I didn't know "it's something we need to figure out" translates to "we refuse to fix it" in whatever language you speak. I'll have to keep that in mind in the future.
Re-writing and refactoring the UI would have been the optimal time to "figure out" the UX errors and shortcomings. Instead, the problems were brought forward into the new codebase where they continue to plague the software. Knowing there was a problem with the first version of the software, and the bringing that same problem forward to the next version of the software, I feel is accurately portrayed with "refused to fix".

In this manner, "something we need to figure out" came out as "something we didn't care enough to address when re-writing our software", which since it was a problem before, and is a problem still, translates as "refused to fix".
Exactly. This has to be a combination of lack of resources (developers) or just poor development practices. I've been using SD DVR on and off since it started and back then the channels dvr didn't even exist. Since then the channels dvr has emerged as the top tier DVR solution combined with excellent apps on all streaming platforms and a very functional web UI. Emby and Plex have both continued to improve their DVR and web UI. All of this has happened while next to nothing happens on the SD DVR side. Months go by and then a "few new look" comes out with everything essentially the same. It's clear that *no one* on the development team watches sports or the watch live issue would have been fixed a long time ago.

If SD had listened to me *years* ago things would be a lot different. They should open source both the DVR engine and the client side. Yes it's true that the community could use that for free and even adapt it to use free guide data like xmltv but you can't really monetize those people anyway. Instead you get to leverage all the incredible development talent out there to provide a top notch DVR engine and front end. This would form the "free" product. SD would then work on the "pro" product that includes DRM recording and playback. SD could take the open source code and use it when building the pro product. SD could charge $100 per year instead of the $35 they were talking about if they had DRM recording and playback and sell it by the sackful. SD could also sell the pro product for $65 per year and that includes non-DRM recording, guide data, and support.

Instead they are stuck in the development model of 20 years ago and getting passed by in the process.

GetMatt
Posts: 1877
Joined: Wed Jan 21, 2009 3:45 pm
Device ID: 1310683C, 13196816, 10733FC0

Re: Seriously?

Post by GetMatt » Fri Jan 03, 2020 4:54 pm

rykr wrote:
Fri Jan 03, 2020 4:29 pm
rpcameron wrote:
Fri Jan 03, 2020 11:14 am
nateb wrote:
Fri Jan 03, 2020 10:35 am


Neat. I didn't know "it's something we need to figure out" translates to "we refuse to fix it" in whatever language you speak. I'll have to keep that in mind in the future.
Re-writing and refactoring the UI would have been the optimal time to "figure out" the UX errors and shortcomings. Instead, the problems were brought forward into the new codebase where they continue to plague the software. Knowing there was a problem with the first version of the software, and the bringing that same problem forward to the next version of the software, I feel is accurately portrayed with "refused to fix".

In this manner, "something we need to figure out" came out as "something we didn't care enough to address when re-writing our software", which since it was a problem before, and is a problem still, translates as "refused to fix".
Exactly. This has to be a combination of lack of resources (developers) or just poor development practices. I've been using SD DVR on and off since it started and back then the channels dvr didn't even exist. Since then the channels dvr has emerged as the top tier DVR solution combined with excellent apps on all streaming platforms and a very functional web UI. Emby and Plex have both continued to improve their DVR and web UI. All of this has happened while next to nothing happens on the SD DVR side. Months go by and then a "few new look" comes out with everything essentially the same. It's clear that *no one* on the development team watches sports or the watch live issue would have been fixed a long time ago.

If SD had listened to me *years* ago things would be a lot different. They should open source both the DVR engine and the client side. Yes it's true that the community could use that for free and even adapt it to use free guide data like xmltv but you can't really monetize those people anyway. Instead you get to leverage all the incredible development talent out there to provide a top notch DVR engine and front end. This would form the "free" product. SD would then work on the "pro" product that includes DRM recording and playback. SD could take the open source code and use it when building the pro product. SD could charge $100 per year instead of the $35 they were talking about if they had DRM recording and playback and sell it by the sackful. SD could also sell the pro product for $65 per year and that includes non-DRM recording, guide data, and support.

Instead they are stuck in the development model of 20 years ago and getting passed by in the process.
You know I looked at using Channels, but unfortunately they don't support the platforms I use and require a much more powerful NAS to run their software. I'm not going to drop a bunch of extra money for that service. You say "all" platforms, but in reality they only support 2 (Android and Apple).

Plex has the same issue with requiring more power and has never consistently been able to record shows for us. When we used it recently it failed to record almost everything we scheduled to record with it.

If you are fine with spending the money in hardware to run those other options you are free to do so. If you don't like the software why are you not just using all of the other "amazing" options and moving on?

rykr
Posts: 346
Joined: Sat Oct 31, 2015 5:09 am

Re: Seriously?

Post by rykr » Fri Jan 03, 2020 6:17 pm

GetMatt wrote:
Fri Jan 03, 2020 4:54 pm
rykr wrote:
Fri Jan 03, 2020 4:29 pm
rpcameron wrote:
Fri Jan 03, 2020 11:14 am


Re-writing and refactoring the UI would have been the optimal time to "figure out" the UX errors and shortcomings. Instead, the problems were brought forward into the new codebase where they continue to plague the software. Knowing there was a problem with the first version of the software, and the bringing that same problem forward to the next version of the software, I feel is accurately portrayed with "refused to fix".

In this manner, "something we need to figure out" came out as "something we didn't care enough to address when re-writing our software", which since it was a problem before, and is a problem still, translates as "refused to fix".
Exactly. This has to be a combination of lack of resources (developers) or just poor development practices. I've been using SD DVR on and off since it started and back then the channels dvr didn't even exist. Since then the channels dvr has emerged as the top tier DVR solution combined with excellent apps on all streaming platforms and a very functional web UI. Emby and Plex have both continued to improve their DVR and web UI. All of this has happened while next to nothing happens on the SD DVR side. Months go by and then a "few new look" comes out with everything essentially the same. It's clear that *no one* on the development team watches sports or the watch live issue would have been fixed a long time ago.

If SD had listened to me *years* ago things would be a lot different. They should open source both the DVR engine and the client side. Yes it's true that the community could use that for free and even adapt it to use free guide data like xmltv but you can't really monetize those people anyway. Instead you get to leverage all the incredible development talent out there to provide a top notch DVR engine and front end. This would form the "free" product. SD would then work on the "pro" product that includes DRM recording and playback. SD could take the open source code and use it when building the pro product. SD could charge $100 per year instead of the $35 they were talking about if they had DRM recording and playback and sell it by the sackful. SD could also sell the pro product for $65 per year and that includes non-DRM recording, guide data, and support.

Instead they are stuck in the development model of 20 years ago and getting passed by in the process.
You know I looked at using Channels, but unfortunately they don't support the platforms I use and require a much more powerful NAS to run their software. I'm not going to drop a bunch of extra money for that service. You say "all" platforms, but in reality they only support 2 (Android and Apple).

Plex has the same issue with requiring more power and has never consistently been able to record shows for us. When we used it recently it failed to record almost everything we scheduled to record with it.

If you are fine with spending the money in hardware to run those other options you are free to do so. If you don't like the software why are you not just using all of the other "amazing" options and moving on?
Trust me I don't want to spend the extra money but every time I ask my wife to use SD DVR after a few days she's like seriously -- is this a joke? :)

I already have a a core i7 16TB Plex server that I run the channels docker container on so hardware is not an issue and the client runs swimmingly on my $25 fire stick 4k. The proper channel guide and automatic commercial skipping are top notch. Believe me I want the SD product to be good and as soon as Plex/Emby become good enough I'll drop channels. Until then....

ota
Posts: 28
Joined: Fri Jul 05, 2019 6:47 am

Re: Seriously?

Post by ota » Sat Jan 18, 2020 10:58 pm

nateb wrote:
Mon Dec 30, 2019 12:54 pm
Right now "Watch Now" only watches the first show in a list. To watch any other show in that list live, you have to go to the Slice guide and browse to the channel the show is on (or wait until it becomes the first show in the list). Fixing this would require a redesign of how we handle the Watch Now button.
You already have a technique to do an action with a row as implemented by deleting a row on the Tasks page with the trash icon. The same technique can be used in the episode list by rendering an additional column and filling it with an eyeball icon if the episode is on right now. When the user selects the icon then tune to its channel. That's a simple implementation using an existing UI technique that doesn't involve the Watch Now button at all.

rykr
Posts: 346
Joined: Sat Oct 31, 2015 5:09 am

Re: Seriously?

Post by rykr » Sun Jan 19, 2020 8:02 am

ota wrote:
Sat Jan 18, 2020 10:58 pm
nateb wrote:
Mon Dec 30, 2019 12:54 pm
Right now "Watch Now" only watches the first show in a list. To watch any other show in that list live, you have to go to the Slice guide and browse to the channel the show is on (or wait until it becomes the first show in the list). Fixing this would require a redesign of how we handle the Watch Now button.
You already have a technique to do an action with a row as implemented by deleting a row on the Tasks page with the trash icon. The same technique can be used in the episode list by rendering an additional column and filling it with an eyeball icon if the episode is on right now. When the user selects the icon then tune to its channel. That's a simple implementation using an existing UI technique that doesn't involve the Watch Now button at all.
Apparently adding an extra button there to directly watch that show would require a complete rewrite of the entire thing. LOL

Post Reply