Bugzilla – Bug 8256
Display offset issue, unreadable text at the left, garbled at the right
Last modified: 2010-11-02 08:50:43 UTC
Created attachment 3378 [details] This is how the LCD Display Error looks like Platform: Vista, nightly 7.1 trunk build 20009, using a Transporter FW42. Issue: Sometimes both of the displays get an offset to the left, leaving the right edge of both display with a garbled border. The border is the same width as the offset (about 2cm). Whenever it goes wrong, the offset remains until the transporter is reset. Restarting SC7 doesn't help, indicating some runtime value in the firmware is off. Also, I haven't been able to reproduce this with either a SB3 or SoftSqueeze, another indication it has to do with FW42. Discussion Thread: http://forums.slimdevices.com/showthread.php?t=48062 The attachment shows how the LCD Display error looks like.
I've now found that is in fact NOT the firmware of the transporter really, but something to do with SC7 in combination with the transporter. I'm now running a somewhat older 7.1 trunk (build 19573) but still using firmware 42. Transporter now operates as it should, no sign of this display bug. So a compare in code 20009 and 19573 should easily find this error......
Hmmm, never mind that. It took a lot longer then last time, but the display error came back.
Sometimes this issue clears up spontaneously for me, but it seems to be present most of the time and cannot be cleared up by a Xilinx or factory reset. Still present in the latest nightly as of today. This is with the .deb file on Ubuntu Linux 8.04, so it isn't dependent on OS.
One more comment, once affected the truncation even occurs in the firmware menu, which led me to believe it was FW42 as well until I read Anton's comment.
Don't see how this can be the server - is there a way to create it? When you have got it what happens if you press and hold left to return to the music source menu which is created by the player itself?
When in the error-state, when holding left, going to the players internal menu, the error persists. (ie. the whole menu is shifted off of the screen). When re-connecting to SC7, nothing changes, need to reset TP in order to get it back correctly (but only for so long until it errors again)
This happens if the data connection between the main board and the UI board becomes out of sync. In the past, I have only ever seen it caused by an electrical transient while working on the unit with the case open. If it happens during run-time then maybe there is a bug in FW40+ that is causing it. It is definitely not a server bug. However if it is shown to happen with one SC version and not another, then it means it's a firmware bug that is being triggered somehow by a situation caused by the server.
As pointed out, I was incorrect in saying that reverting back to an earlier version of SC7 resolved the problem. The problem probably lies with FW42 alone.
I haven't seen it before FW42 either, BUT...it first started when there was a power interruption. When it came back up the display got to be like this very quickly.
I'm seeing this as well, starting right after I switched from 7.0 to 7.2; it looks very similar to the photo Anton posted. I can play around with different server/firmware versions this weekend if you'd like.
This disappeared for several firmware versions but it's back with FW50.
I see this as well, and quite frequently as of late. I'm using fw56 (not yet upgraded to 59)
Do you have IR blaster enabled? Felix has just identified and fixed a problem that was causing this. If there are other causes of it then we need to look into this further.
What do I need to get to get this "fix"? the latest firmware, or a new IRblaster plugin? (I am using IR blaster)
I have only the IR repeat feature enabled on the Transporter.
I do have IR Blaster. I'll look to see if Felix has a new version and report back.
The bug fix needed to solve this is in TR firmware, not in the IRBlaster plugin.
when can we expect this fixed firmware to be in the trunk?
I don't have IR Blaster, but I am using PowerSwitch II; presumably that'd trigger it in the same way?
It's in fw 60, which should be in the 7.2 trunk.
I just had a recurrence w/ fw 61.
Hmm, I am unable to reproduce in my system? Do you recall what you did to make it happen? I guess you changed the volume, no? Would you mind attaching your IRBlaster .conf file? Maybe there is something in there which more likely causes this issue. Thanks.
no volume control. I wasn't even using the Transporter at the time, except that it functions as a repeater for the IR. The only remote in use is a Harmony One which was mostly issuing MythTV command signals.
Created attachment 3811 [details] prefs file.
Ok, so it happens with IR repeating. I've just tried that here and have thrown about every remote I have at it, pressing buttons randomly, but I wasn't able to reproduce. Hmmm. Does it happen with any remote or one particular you are using?
I only have the Harmony One with batteries (I'll assume you have one as well. If not, you should use this as the excuse). I'll see if I can dig up the hauppauge remote to see if anything happens.
I've got a Harmony One. :) So, if you tell me the exact device / brand etc. I can program mine and try it myself. Thanks
I'm not going to be home today to check, but the Harmony software used to have a web url for configuring, but I lost it. Do you know it? If so, I can check from here and let you know what the device is, according to Harmony (in MythtV speak, it's only known as the Hauppauge Silver remote but Harmony treats is as a generic "MythTV" option I think)
The specific device I've been using for the Harmony One settings is "HauppaugeWinTV-PVR-150". I have only had it trigger the effect the one time.
Thanks, KDF, I will try to reproduce with that device.
I have had this issue for several months - using 7.3.xx sc. Not sure which fw is in the tranporter but will check when I get home. I use IR blaster to turn on/off my PA's and weather underground as screen saver. The bug seems to depend on what was being shown on the screen just before. Eg I have some extended song info up that needs scrolling - the display suddenly shows offset (not quite sure what triggers it) I then reboot the transporter - it will start up - get its ip address etc and then flip into the offset display again. To get it out of this state I need to navigate to something that has shorter display text and then reboot - it will recover. I use an enlarged display text - though NOT the largest. It is VERY easy to get it to go wrong it is very annoying. I also find that IR blaster has died - needing a reboot of the transporter - not sure there is a 100% link there - but there is a link of sorts at least some of the time- they both occur together. coppo
Further to my last post - My transporter FW is 43 Coppo
Coppo: Please upgrade your TR firmware to at least version 60, see comment #20.
Thanks. i had gone back to 7.2 from a beta 7.3.xx for other reasons a week or two ago and made sure that all the hardware was up to date at the same time. My TP FW is now 60 and I haven't seen the offset display issue since. Cheers
All right. Even though we didn't explicitly check in a fix for this, it looks like it's working for you, Andy. If you see it again, or if anyone else does, please reopen the bug.
This just happened again for me with FW71. removing target for another review.
QA to have a look
QA does not have a Harmony One. All the remotes I have here do not cause this error. Felix/KDF - what steps should we take next? Moving target to monitor for now. Please change if you feel strongly
happened again just after the update to fw73. It's not a "remote" issue, but an issue of the Transporter display. Sean mentioned before that it's a timing issue, so perhaps it's a risk when changing firmware. Either that, or it's a condition that shows up after recent updates. Both cases I've seen have been shortly after a fw update, and it does seem to go away (unless I'm just forgetting fw72 having fixed what happened in 71) My default setting for idle is rss saver with a patch to show the weather on the right display. Maybe the scrolling sets it off more often that other options?
Thanks for the update. To clarify: It's a display thread timing issue which is more critical on TR because the thread has to serve two displays (instead of only one). In addition the display thread also contains the ir blasting code. This means using ir blasting could also make it more likely to happen. The change to the ir blasting code in fw 60 was to split up the code in smaller chunks to reduce the time in that part of the code per iteration. My current guess it that there is some variance in the overall display thread timing (maybe hw related) and if it's on the edge it can still happen.
seems to be back with a vengeance using FW77. After a power reset, it's only a matter of hours before it's back. reverting to 76 to give it some time and see if that makes the difference.
fw80 still has the same issue.
Hey Kevin, thanks for the update. I would have been surprised if it was solved by itself as I did nothing to fix it. But first I need to be able to reproduce on my TR. :(
No problem. I didn't expect a fix, just updating the notes. I got the impression that it's not a problem with all units, but that certain ones are prone. The one that I have hooked up is a beta unit currently, but my production one also was prone to the issue. I mostly use the beta since I don't currently have a good playback use for it; it serves as a display mostly (IR repeater as well if it worked, but i believe it wasn't supported in that hardware)
Exactly the same appearance intermittently - added ir blaster plug in and running 7.4. ReadyNAS duo Only transporter affected SB3 ok
Are people still experiencing this regularly? Felix, do you think it would be constructive to RMA an affected unit and see if it's something specific to the individual Transporter?
I've bypassed my transporter.version file to stick with 77 all of this time.When I've forgotten the patch, and it updates to 80, it will eventually fail and remind me that I have to set it all back for fw77. I have a beta unit, but I've never managed to get the IR blaster function working on that one (not sure if hardware is simply not there in that version) so can't consider the comparison as completely valid.
Kevin - are you saying fw 77 works better for you? Beta units should also support IR Blaster. But you need to make sure you are using an IR emitter with a stereo jack. There was a layout error on the board which connected left and right together. So if you plug in a mono jack it shorts the right channel to ground and therefore the left channel too.
FW77 works solidly for me. 80 will fail within a day, or at least that has been the result when I have tried it before.
Are you positive that the firmware version is 77? According to my notes and what I can see checked into svn there is no Transporter firmware version 77. I only see 76 and 80.
I may have named it incorrectly when I pulled it from a backup. I'll get 76 from svn and confirm.
Firmware 77 shows up here. http://svn.slimdevices.com/slim?view=revision&revision=27036
Ok, got it, thanks. This revision slipped through my radar due to the fact that it was done late to the 7.3 branch by Andy. It should be the same as 76 from 7.4 branch. Anyways, the only change after that is my fix to digital inputs, some string translations and some minor fix Andy did and that is what went into firmware 80. Did you have a chance to try your beta unit?
not yet. house is crowded these days, so hard to get the time to dig it out and rewire.
Using the beta now, and one day later it has started showing the problem as well with FW80. Restarting and reverting to FW77 fixes it.