Jump to content


  • Content Count

  • Joined

  • Last visited

  1. well for one there is the issue of massive slow down on bandwidth that severely hinders mutli-device homes and networks; for instance i have an asus rt-ac68p router, its great router but kinda sucks on upnp and console gaming (pc less an issue with correct port forwards) this router gets massively better downloads (max speed i've gotten consistently is about 150mbps from various internet sources) and streaming rates but does not play nice with the r1 if i connect it behind or in front of the R1 contrary to that the r1 despite being capable of about 800mbps lan speeds can barely maintain a 5 or 6 Megabyte per second link on downloads or streaming (so about 45 to 60 megabits) this is even with just one device connected and all settings set to allow that device full bandwidth utilization and every possible combo of settings that i can tweak. so the dumaos update is supposed to handle the networking better than the original r1 firmware; if this is the case it may allow those like me with this kind of issue to actually use the r1 without knocking everyone else off the network or severely tanking their connections. there are other issues like upnp and device allocations being unable to be handled manually but i cant speak to those being changed in the dumaos or not since i don't know if it is something that got changed or not.
  2. well for one this gives us zero further insight as this is just rehashing what everyone is already aware of so big fat F- on that attempt at clarification. if they are keen on "actions rather than words" then maybe someone should tell them that the reverse is also very true; a complete lack of visible action in any way, shape, or form is just as bad as the the circus that surrounded the ETA announcements. you have to pick one or the other if you want to avoid a completely negative PR perspective on the consumer side: you either announce what your doing regardless if that's an eta or a periodic status report or whatever with some meaningful information or B: you make progress and show it on a regular basis (the beta would have been a perfect example of option B but that never went anywhere at all due to who knows why, and bugs are not a valid excuse as a beta is already from the start assumed to be buggy; that's the whole point of having a beta phase.) any other option that removes both of those is just a PR shitstorm waiting to happen with an near exponentially rising risk of occurrence the longer that it is allowed to continue. right now the "its coming", "soon", "its right around the corner" BS filler answers are starting to be perceived as just that: filler answers to avert mass consumer loss of confidence. so unless that "around the corner" is within the next 2 to 4 weeks people will probably start to hear or see yours guy's words in a "cry wolf" light and will seldom take anything said at face value and automatically assume that it likely won't amount to anything substantial or assume that its BS until it actually happens (or doesn't and then the whole "see they jerked it around again" scenario will begin with the accompanying bad PR) no one is saying the communication has to be an ETA but there needs to be something; a bug list, a progress report, anything; and any excuse about the devs not having time to do that is honestly disingenuous at best. any dev worth a damn has a list of bugs they are working on or know of that need to be worked on, it would literally take 30 seconds at most to format it in a readable form and post that on the forums once a week. it doesn't need to be a giant "proofed for marketing" kind of post; just show progress, if you or anyone else expect anyone to believe that a developer, even on a small team doesn't have 30 seconds to spare in the course of a WEEK you'll be sorely disappointed on people's responses.
  3. well considering there has been no news at all from any of them other than what amounts to "we're working on it" in months and at the same time touting the xr500 to boost sales someone needs to give some meaningful info. and while we know you guys "can't speak for the development team" you can certainly speak TO them and tell them to give some kind of statement or to relay one from them; silence is not acceptable considering that multiple times statements were made and then failed to follow through on and then no info as to why they failed other than some vague answer about getting the bugs out or some such with no real info behind it. honestly someone on the net duma side needs to say SOMETHING with substance or i could easily forsee a class action for false advertising or deceptive practices among other things. the fact that the update is (or at least has been promised; yet to see it obviously but the xr500 seems to have gotten it just fine) going to be provided to r1 buyers for free is irrelevant until that actually happens, its been promised (just like the beta, which didn't really happen) again and again and yet we still have jack squat. meanwhile the xr500 has it running just fine; if the hardware difference is that insurmountable (which isnt that hard to imagine if in fact that is a factor at all; would have to see code but you shouldn't NEED 1.7ghz to run firmware in most cases) then it should have been stated up front and not used as a selling point (another point that would lend to a class action BTW). honestly i want this thing to succeed but it seems that either management or the dev team is determined to not want this or care about it (which is the direct consequence of not giving any meaningful statements; people have no way to know or think otherwise when there is no communication)
  4. dont see why you cant ditch the ISP's issued router/modem and buy one yourself that you know you can configure? if you have your authentication info from your account to input into the new router their network should not care as long as the capabilities are the same, unless it does some kind of make/model match and white-lists the connection based on that (though i doubt it; that'd be a rather big drain on the back end to poll all downstream devices for a model/make/bios rev to authenticate)
  • Create New...