|
|
Post by hsamwel on Feb 24, 2021 12:58:44 GMT -5
Ok. This is the proof I needed that we all have different preferences. This is exactly how my system behaves. To me this slow and laggy. You can see the redraw being done while you watch. Which IMO should redraw the whole screen in less than a blink of an eye. That speed is exactly like my OPPO menu navigation.  I just opened my OPPO BDP-103 menu and it’s atleast 5 times faster in the redraw. Actually I can’t even see the screen redraw. It does it in one go. It feels like Emotiva doesn’t use double or tripple buffering for the page redraws. Old PC’s usually had very slow overlay handling due to bad drivers and letting the CPU handle it. I remember many newer drivers added buffering to better deal with the screen refresh. But OPPO has a slight delay between each page, maybe a 1/3 second or so. If I scroll up and down fast it has no delay though. It has no feel of lagging, no visual delay and all is updated at the same constant speed. With RMC there’s lagging (from remote press), slow redraw and different speed (sometimes lags, sometimes not) OPPO’s menu design, looks and feel isn’t a bad place to start for Emotiva to change to IMO. I don’t remember my OPPO UDP-203 being any slower in the settings?! If you feel these are on par then you have serious problems with your OPPO, or a prepro on steroids..  |
|
|
|
Post by wcassinc on Feb 24, 2021 13:27:56 GMT -5
After installing FW 2.2 I get many pops and clicks, loud and soft, when changing between programs/songs/apps especially on Apple TV 4K -- it seems others have the same issue. Is there a fix/work around for this? Or do we wait for the next FW release?
|
|
cawgijoe
Emo VIPs 
"When you come to a fork in the road, take it." - Yogi Berra
Posts: 5,033
|
Post by cawgijoe on Feb 24, 2021 13:36:09 GMT -5
After installing FW 2.2 I get many pops and clicks, loud and soft, when changing between programs/songs/apps especially on Apple TV 4K -- it seems others have the same issue. Is there a fix/work around for this? Or do we wait for the next FW release? I have very few pops/ticks with any of my sources. had more in earlier releases with ATV4K. Emotiva is aware. Likely will be in the next FW release. Send them an email or give them a call and let them know. The more people that let them know officially, the higher the priority in terms of testing on their end and fixing. |
|
|
|
Post by megash0n on Feb 24, 2021 14:26:49 GMT -5
After installing FW 2.2 I get many pops and clicks, loud and soft, when changing between programs/songs/apps especially on Apple TV 4K -- it seems others have the same issue. Is there a fix/work around for this? Or do we wait for the next FW release? I have very few pops/ticks with any of my sources. had more in earlier releases with ATV4K. Emotiva is aware. Likely will be in the next FW release. Send them an email or give them a call and let them know. The more people that let them know officially, the higher the priority in terms of testing on their end and fixing. it's a dang shame they don't have a website where you could submit tickets and bugs. Or, to check to see if an existing bug matches your experience so you can say "me too". These "near-free" solutions would provide data-driven analysis to better serve the customer while drastically cutting down support calls and board chatter. |
|
|
|
Post by megash0n on Feb 24, 2021 14:39:36 GMT -5
Emotiva has been quoted many times stating there could be issues with the cable plugged in. We just all experience something different at times, and over time. My NIC issues are a prime example. I've had such a frustrating time with my NIC for the first 10ish months of ownership. It hasn't stopped working for me ... Well, y'all get the point. If I actually say it.. I'll go home and it will end up being down for some reason. No rhyme of reason as to why it has decided to function electrically better over the past couple months. I wish I could unplug it, but I have to use the API. Well, I guess I could technically use other options as well. Just trying to stay current with times I guess. Isn’t there a way you could run a alpha/beta version with bug/crash logging so Emotiva could see exactly what’s happening to the ethernet? It’s so 80’s that you have to tell them you have a bug and they search for it (like a needle in a haystack). Most compilers can do code with automated logging nowadays I’m sure. I also have no issues whatsoever. I have my RMC-1 connected 24/7. Never had an issue with firmware 1.5 til now. I have RMC set to static with all IP’s locked to MAC’s in my router (ASUS). I'm not sure I'm following your message. I also really don't know how to answer these things. Some of you guys never have an issue. And then you read daily of other users having issues. Like.. Basic stuff with brand new units bricking or malfunctioning. I think we can all agree that it is a crap shoot whether you get a lemon or an orange. There certainly has to be a bucket of root causes for all of this that we may never know. Totally crap code would likely have an impact at a greater scale. I have a suspicion that it is a sprinkling of a whole lot of things. One being random component purchases in bulk because they are a good value at the time. They may fit into a tolerance on paper, but in practice, and with all the other minor things, batches of processors tend to work better or worse than others. You aren't problem free because you are special in some way. You are problem free because you either received a hand picked unit, or you received a unit with better components. The next guy, a year later, doesn't have a bricked processor because he's stupid and can't manage to plug an RCA cable in straight. It bricks because something inside that shipping box is trash. Some of these things are pretty basic logic. After more than a few people have an issue, your company's reputation is on the line. You gotta sort through it and take ownership. Ignoring it and hiding from it is close to the worst possible choice. Anyways, I am happy for you. I truly wished I had a wonderful experience because I would far rather keep this gear than to sell it for something else. |
|
|
|
Post by hsamwel on Feb 24, 2021 14:59:34 GMT -5
Isn’t there a way you could run a alpha/beta version with bug/crash logging so Emotiva could see exactly what’s happening to the ethernet? It’s so 80’s that you have to tell them you have a bug and they search for it (like a needle in a haystack). Most compilers can do code with automated logging nowadays I’m sure. I also have no issues whatsoever. I have my RMC-1 connected 24/7. Never had an issue with firmware 1.5 til now. I have RMC set to static with all IP’s locked to MAC’s in my router (ASUS). I'm not sure I'm following your message. I also really don't know how to answer these things. Some of you guys never have an issue. And then you read daily of other users having issues. Like.. Basic stuff with brand new units bricking or malfunctioning. I think we can all agree that it is a crap shoot whether you get a lemon or an orange. There certainly has to be a bucket of root causes for all of this that we may never know. Totally crap code would likely have an impact at a greater scale. I have a suspicion that it is a sprinkling of a whole lot of things. One being random component purchases in bulk because they are a good value at the time. They may fit into a tolerance on paper, but in practice, and with all the other minor things, batches of processors tend to work better or worse than others. You aren't problem free because you are special in some way. You are problem free because you either received a hand picked unit, or you received a unit with better components. The next guy, a year later, doesn't have a bricked processor because he's stupid and can't manage to plug an RCA cable in straight. It bricks because something inside that shipping box is trash. Some of these things are pretty basic logic. After more than a few people have an issue, your company's reputation is on the line. You gotta sort through it and take ownership. Ignoring it and hiding from it is close to the worst possible choice. Anyways, I am happy for you. I truly wished I had a wonderful experience because I would far rather keep this gear than to sell it for something else. What I mean is, could Emotiva provide you with firmware with a built-in logger? Most modern compilers do provide this feature, it shouldn’t be impossible for Emotiva either. Instead of manually disecting the code for faults, which can take like forever. This way they would also know if it’s the hardware or software that’s failing. |
|
|
|
Post by megash0n on Feb 24, 2021 15:14:16 GMT -5
I'm not sure I'm following your message. I also really don't know how to answer these things. Some of you guys never have an issue. And then you read daily of other users having issues. Like.. Basic stuff with brand new units bricking or malfunctioning. I think we can all agree that it is a crap shoot whether you get a lemon or an orange. There certainly has to be a bucket of root causes for all of this that we may never know. Totally crap code would likely have an impact at a greater scale. I have a suspicion that it is a sprinkling of a whole lot of things. One being random component purchases in bulk because they are a good value at the time. They may fit into a tolerance on paper, but in practice, and with all the other minor things, batches of processors tend to work better or worse than others. You aren't problem free because you are special in some way. You are problem free because you either received a hand picked unit, or you received a unit with better components. The next guy, a year later, doesn't have a bricked processor because he's stupid and can't manage to plug an RCA cable in straight. It bricks because something inside that shipping box is trash. Some of these things are pretty basic logic. After more than a few people have an issue, your company's reputation is on the line. You gotta sort through it and take ownership. Ignoring it and hiding from it is close to the worst possible choice. Anyways, I am happy for you. I truly wished I had a wonderful experience because I would far rather keep this gear than to sell it for something else. What I mean is, could Emotiva provide you with firmware with a built-in logger? Most modern compilers do provide this feature, it shouldn’t be impossible for Emotiva either. Instead of manually disecting the code for faults, which can take like forever. This way they would also know if it’s the hardware or software that’s failing. I gotcha. First, they'd have to genuinely care about the problem that many customers have. We can't get anywhere without that. Secondly, they'd have to make an update (most likely) to the kernel... Which hasn't happened since 2018. I suspect they already know why the NIC does and not not "electrically" work for some from time to time, but don't feel it is significant enough to fix. Instead, they have focused on another new processor, headphones, a redesigned website, a handful of new speakers, Dan's toy garage cleanup, and on and on and on. This gets back to the root of what I've argued for over a year. Anyone with passion can fix these technical issues. The desire to take pride in everything you do must be there, or the "fix" is momentary. It's a good idea though. 😊 |
|
KeithL
Administrator 
Posts: 10,261
|
Post by KeithL on Feb 24, 2021 16:00:01 GMT -5
The problem is that, when you have processes that run in real time, the logging code itself alters the timing... And adds more of a processing load... And offers the opportunity for the added code to cause new and different problems...
And offers the opportunity for the log files themselves to overflow and cause problems... And, since the code isn't physically monitoring the hardware, it can only tell you when the code stopped...
And, of course, if your logger crashes, then it won't have time to save the data you want anyway...
It reminds me of a very humorous thing that happened way back when I was in high school... One of our computers sprang to life and typed: "System going down in..........." Of course it never completed the message... because it had crashed...
We do have such things... And we use them when and where useful and appropriate...
But they are not a silver bullet by any means...
I'm not sure I'm following your message. I also really don't know how to answer these things. Some of you guys never have an issue. And then you read daily of other users having issues. Like.. Basic stuff with brand new units bricking or malfunctioning. I think we can all agree that it is a crap shoot whether you get a lemon or an orange. There certainly has to be a bucket of root causes for all of this that we may never know. Totally crap code would likely have an impact at a greater scale. I have a suspicion that it is a sprinkling of a whole lot of things. One being random component purchases in bulk because they are a good value at the time. They may fit into a tolerance on paper, but in practice, and with all the other minor things, batches of processors tend to work better or worse than others. You aren't problem free because you are special in some way. You are problem free because you either received a hand picked unit, or you received a unit with better components. The next guy, a year later, doesn't have a bricked processor because he's stupid and can't manage to plug an RCA cable in straight. It bricks because something inside that shipping box is trash. Some of these things are pretty basic logic. After more than a few people have an issue, your company's reputation is on the line. You gotta sort through it and take ownership. Ignoring it and hiding from it is close to the worst possible choice. Anyways, I am happy for you. I truly wished I had a wonderful experience because I would far rather keep this gear than to sell it for something else. What I mean is, could Emotiva provide you with firmware with a built-in logger? Most modern compilers do provide this feature, it shouldn’t be impossible for Emotiva either. Instead of manually disecting the code for faults, which can take like forever. This way they would also know if it’s the hardware or software that’s failing. |
|
KeithL
Administrator
Posts: 10,261
|
Post by KeithL on Feb 24, 2021 16:02:08 GMT -5
The Volume Control actually operates internally at smaller steps than you can access using the control... Sometimes they get out of synch with what they're being told to do... Then you reset things... And they're back in step again...
Weird volume abnormality post Dirac calibration. Twice after running a Dirac calibration with firmware 2.2 my volume display has a .5 added to it (eg. 20.5, or 23.5). Thankfully, a simple power cycling fixes it. Some good news with 2.2 is that thus far I have been able to pause streaming services on my Tivo based cable box without the RMC-1 locking up. With 2.1 I couldn't pause for more than 1-2 minutes. This .5 issue has been mentioned many times before. Not sure why it happens, but the power cycle seems to fix it. |
|
KeithL
Administrator
Posts: 10,261
|
Post by KeithL on Feb 24, 2021 16:05:55 GMT -5
It sounds like Sony fixed something... cool.
Note to all... in case you didn't realize it.
ARC is part of HDMI-CEC ... so ARC WILL NOT WORK unless HDMI-CEC is enabled. However, on our processors, only the "main master HDMI-CEC check box" needs to be checked.
At least in theory none of the other HDMI-CEC settings should have any effect on ARC.... note that I said in theory there.
Thanks, does not work for me unfortunately. I'm using lowest power as well. Do you get into the apps before the processor fully boots? I'm so desperate, I'll try any exact sequence. After the last Sony tv firmware update which wiped all settings, I hadn't used ARC so I couldn't remember the key settings to look for, so I did a "Initial Setup" on the Sony tv. This made it easy. The only item in checked in XMC-2 Setup:: HDMI CEC is Enable, nothing else is checked. CEC is not enabled on anything in my system except for this setting. So then I just started the Initial Setup on the tv. This is what it looked like. In the third image you can see that the tv detected the XMC-2. The XMC-2 factory default is for HDMI CEC to be Enabled, I used to turn this off but lately I've kept it enabled. I setup Button #6 on the remote for ARC and it works when I choose #6 first or if I start streaming on the tv first, either way. I don't have any sources connected to the tv, so it's just the apps streaming from the tv. View Attachment View Attachment View Attachment View Attachment |
|
|
|
Post by megash0n on Feb 24, 2021 16:44:48 GMT -5
I have very few pops/ticks with any of my sources. had more in earlier releases with ATV4K. Emotiva is aware. Likely will be in the next FW release. Send them an email or give them a call and let them know. The more people that let them know officially, the higher the priority in terms of testing on their end and fixing. it's a dang shame they don't have a website where you could submit tickets and bugs. Or, to check to see if an existing bug matches your experience so you can say "me too". These "near-free" solutions would provide data-driven analysis to better serve the customer while drastically cutting down support calls and board chatter. For the record, instead of just pissing and moaning about an issue, I'm happy to provide a solution. I'll volunteer my time to build a consumable system for all of this. There is only one caveat. It has to be used by Emotiva to track tickets and bug reports so each and every consumer knows their information matters. |
|
|
|
Post by hsamwel on Feb 24, 2021 16:49:03 GMT -5
The problem is that, when you have processes that run in real time, the logging code itself alters the timing... And adds more of a processing load... And offers the opportunity for the added code to cause new and different problems...
And offers the opportunity for the log files themselves to overflow and cause problems... And, since the code isn't physically monitoring the hardware, it can only tell you when the code stopped...
And, of course, if your logger crashes, then it won't have time to save the data you want anyway...
It reminds me of a very humorous thing that happened way back when I was in high school... One of our computers sprang to life and typed: "System going down in..........." Of course it never completed the message... because it had crashed...
We do have such things... And we use them when and where useful and appropriate...
But they are not a silver bullet by any means...
What I mean is, could Emotiva provide you with firmware with a built-in logger? Most modern compilers do provide this feature, it shouldn’t be impossible for Emotiva either. Instead of manually disecting the code for faults, which can take like forever. This way they would also know if it’s the hardware or software that’s failing. Are you saying because a logger could crash or overflow there’s no reason to try to log? Other programs use this feature all the time. Among other nice code testing features. These betas with loggers activated should not be spread in public. So if they crash or misbehave is really not a problem. Btw you could simply log the startup as it seems the issue with the NIC is located there. Btw could you inform us why the Kernel hasn’t been updated since jan 2018 while your here? There must have been A LOT of bug fixes and improvements in Linux since then? And speed? Maybe this alone could help with the NIC issue? |
|
KeithL
Administrator
Posts: 10,261
|
Post by KeithL on Feb 24, 2021 16:51:16 GMT -5
No... I'm saying that we do have the ability to run a unit that way... and do so when we see a purpose in doing so. (But that it still doesn't necessarily solve all the problems.)
The problem is that, when you have processes that run in real time, the logging code itself alters the timing... And adds more of a processing load... And offers the opportunity for the added code to cause new and different problems...
And offers the opportunity for the log files themselves to overflow and cause problems... And, since the code isn't physically monitoring the hardware, it can only tell you when the code stopped...
And, of course, if your logger crashes, then it won't have time to save the data you want anyway... It reminds me of a very humorous thing that happened way back when I was in high school... One of our computers sprang to life and typed: "System going down in..........." Of course it never completed the message... because it had crashed...
We do have such things... And we use them when and where useful and appropriate...
But they are not a silver bullet by any means...
Are you saying because a logger could crash or overflow there’s no reason to try to log? Other programs use this feature all the time. Among other nice code testing features. These betas with loggers activated should no be spread in public. So if they crash or misbehave is really not a problem. Btw you could simply log the startup as it seems the issue with the NIC is located there. Btw could you inform us why the Kernel hasn’t been updated since jan 2018 while your here? There must have been A LOT of bug fixes and improvements in Linux since then? And speed? Maybe this alone could help with the NIC issue? |
|
ttocs
Global Moderator
I always have a wonderful time, wherever I am, whomever I'm with. (Elwood P Dowd)
Posts: 8,160
|
Post by ttocs on Feb 24, 2021 16:52:51 GMT -5
I have very few pops/ticks with any of my sources. had more in earlier releases with ATV4K. Emotiva is aware. Likely will be in the next FW release. Send them an email or give them a call and let them know. The more people that let them know officially, the higher the priority in terms of testing on their end and fixing. it's a dang shame they don't have a website where you could submit tickets and bugs. Or, to check to see if an existing bug matches your experience so you can say "me too". These "near-free" solutions would provide data-driven analysis to better serve the customer while drastically cutting down support calls and board chatter. Just like Dirac has. |
|
KeithL
Administrator
Posts: 10,261
|
Post by KeithL on Feb 24, 2021 16:59:55 GMT -5
We actually have a very effective bug tracking solution... it's just not open to the public. And, for that matter, we also have a pretty good automated system for tracking support calls.
Perhaps you should consider designing a processor, avoiding all the foolish errors we keep making, and give us some serious competition... I'm sure if you actually could design and produce a superior processor, at a similar or lower price to ours, there would be plenty of customers eager to buy it.
it's a dang shame they don't have a website where you could submit tickets and bugs. Or, to check to see if an existing bug matches your experience so you can say "me too". These "near-free" solutions would provide data-driven analysis to better serve the customer while drastically cutting down support calls and board chatter. For the record, instead of just pissing and moaning about an issue, I'm happy to provide a solution. I'll volunteer my time to build a consumable system for all of this. There is only one caveat. It has to be used by Emotiva to track tickets and bug reports so each and every consumer knows their information matters. |
|
Lsc
Emo VIPs
Posts: 3,434
|
Post by Lsc on Feb 24, 2021 17:11:17 GMT -5
I'm not sure what you mean. There is no setting - it's just how it works out of the box. VRO? You using ARC or CEC. Is your HDMI CEC enable and any other function enable? Ah thank you. VRO - yes I always have this turned on HDMI CEC is enabled but I disabled the Input Change I have triggers turned on 3 Dirac settings Input 2 on turn on Volume -40 on turn on |
|
|
|
Post by megash0n on Feb 24, 2021 17:25:29 GMT -5
The problem is that, when you have processes that run in real time, the logging code itself alters the timing... And adds more of a processing load... And offers the opportunity for the added code to cause new and different problems...
And offers the opportunity for the log files themselves to overflow and cause problems... And, since the code isn't physically monitoring the hardware, it can only tell you when the code stopped...
And, of course, if your logger crashes, then it won't have time to save the data you want anyway...
It reminds me of a very humorous thing that happened way back when I was in high school... One of our computers sprang to life and typed: "System going down in..........." Of course it never completed the message... because it had crashed...
We do have such things... And we use them when and where useful and appropriate...
But they are not a silver bullet by any means...
Are you saying because a logger could crash or overflow there’s no reason to try to log? Other programs use this feature all the time. Among other nice code testing features. These betas with loggers activated should not be spread in public. So if they crash or misbehave is really not a problem. Btw you could simply log the startup as it seems the issue with the NIC is located there. Btw could you inform us why the Kernel hasn’t been updated since jan 2018 while your here? There must have been A LOT of bug fixes and improvements in Linux since then? And speed? Maybe this alone could help with the NIC issue? When one pulls a thread, it's always interesting to see where it leads. An awful lot of valid questions there. Unfortunately, the largest portion of our community wants to hit the power button and assume what they have is working properly. |
|
|
|
Post by megash0n on Feb 24, 2021 17:26:16 GMT -5
it's a dang shame they don't have a website where you could submit tickets and bugs. Or, to check to see if an existing bug matches your experience so you can say "me too". These "near-free" solutions would provide data-driven analysis to better serve the customer while drastically cutting down support calls and board chatter. Just like Dirac has. Just like most any company selling consumer products. |
|
|
|
Post by megash0n on Feb 24, 2021 17:30:49 GMT -5
We actually have a very effective bug tracking solution... it's just not open to the public. And, for that matter, we also have a pretty good automated system for tracking support calls.
Perhaps you should consider designing a processor, avoiding all the foolish errors we keep making, and give us some serious competition... I'm sure if you actually could design and produce a superior processor, at a similar or lower price to ours, there would be plenty of customers eager to buy it.
For the record, instead of just pissing and moaning about an issue, I'm happy to provide a solution. I'll volunteer my time to build a consumable system for all of this. There is only one caveat. It has to be used by Emotiva to track tickets and bug reports so each and every consumer knows their information matters. My issues aren't technical in nature. They all point to leadership. Up and down the chain of command. Review my complaints for 13 months. They all point to the same place. You should consider being cautious when stating your bug tracker is effective, when in fact, you continue to repeat the same bugs. I'm not really looking for a war here, but you aren't doing yourself ANY favors by how you are speaking. You are the FACE of this company to thousands of consumers. I'm not sure if you realize that or not. |
|
|
|
Post by bitzerjdb on Feb 24, 2021 17:53:38 GMT -5
For a number of years, I ran a Global ITSM system for a major Pharmaceutical company. The best thing we ever did was put in a bug tracker open to the users. It did a number of things for us, first, it provided an estimate of how many people were being impacted by a specific bug (meaning it got more attention), and second, it stopped the repeat questions in our User forums.
Finally, related to the first point, we knew who to contact when we were working on a specific bug.
This is all I'm going to say on this matter, it is your company and you can run it as you see fit.
|
|
I just opened my OPPO BDP-103 menu and it’s atleast 5 times faster in the redraw.
