I should have the single port card by Monday. I guess if that doesn’t solve the problem, that might be the next place to go. It always goes from 0 to 1.
So what you are saying now leads to to think the swticher itself. So the thing to look at is page 8 of the manual, You’ll see there are 2 switches that set the ID
ID SW 1 and SW2
0 OFF OFF
1 ON OFF
2 OFF ON
3 ON ON
Then figure out what ID the TT software expects either 0 or 1? You may try turning on SW2 and seeing if it jumps between 2 and 3 that would probably confirm that it is the SW1 DIP switch… in which case you may be able to open up the case and fix it with a soldering iron if you are feeling confident or perhaps if it is still under warranty call up the manufacturer and get it fixed.
I will take a look tomorrow. What is “0 off off 1 on off 2 off on 3 on on”? Is this where they are suppose to be? I am assuming the software expects to see the same numbers, port 0 ss 4.4#0 or port 1 ss 4.4#1. It only seems to work when the numbers are the same.
OK, all switches are OFF, except 8 for the PIP triggers. I have the old 4.2 switcher. Would it work with that one?
The screenshot from yesterday. It has been perfect for 24 hours now.
Thanks Bruce, the screenshot comes up fine
So the “plugged into” combo box always goes “pc_serial0”, no change there, right?
And the bug you are observing, is the “switchers found” label below, which sometimes reports about switcher #0 and sometimes about a (fictive) “switcher #1” ?
2 Likes
That is correct! I am limited as to how many posts/replies I can make!
Sorry about that; I’ve increased your “trust level” which should remove those restrictions.
2 Likes
Those are the settings of the physical switches on the switcher… damage to them could cause the switcher to thing it’s ID was different. Perhaps vibration could be a factor also if the switches are damaged or faulty.
That could be caused by a problem in CC, or in the switcher (or less likely, corruption of the data stream in between).
From the log, I see you’re using CC 5.3.2. Looking at the code for that version, it cannot possibly generate “ss4.4 #1” on its own, it should be preceded by something, then a “,” comma, then “ss4.4… #1”. (in tech lingo, the #0 digit is not a switcher unit number, it’s just a for() loop integer, indexed to zero).
==> question re. label – can you take a screenshot of the same window/tab, when it displays “…#1” ? I want to see what’s before it.
As to suspicions about the unit number,
Let’s activate terminal tracing with the hidden “ttcc_trace_hal” flag. That will display serial traffic, what CC makes of the unit number and so on. I’ll look especially at the beginning and the end (right after the bug/“digt hop” occurs), but we’re still talking of hundreds of KB of text, way too much to post in this forum.
==> Get in touch with me in email (use my nickname, followed by “@netcourrier dot com”).
There are known ways that serial traffic can get troublesome, when e.g. an app is restarted and re-opens the serial port again; but i’m assuming nobody is restarting CC behind your back when the computer is unattended.
(edit) Another pattern to look for is if the bug occurs at the same time every day. That would hint at a particular sequence of ProgramLog commands triggering the bug. From the above discussion this does not quite seem to be the case though.
Reminder to self – when I look at tracing, should check which version of SS4.4 is used; our code was tested against “SS4.4 V:1.7”
There’s a faint chance that with this new PCI setup we can open the serial port with SerialConnect (after closing down CC) and using the probing commands…
*0U
*1U
*POLL
Something to try out later maybe, depending on our findings.
In case it matters later, I see you’ve updated the “care package” .zip; it now mentions the new device:
KERN: e[32mpc_serial:e[0m Skipping port 0 as it is used for kernel debug.
KERN: e[32mpc_serial:e[0m scanning PCI bus (alt)...
KERN: e[32mpc_serial:e[0m found PCI device 15 [7|0|2] 9710:9835 as MosChip 16550 Serial Port
KERN: e[32mpc_serial:e[0m irq line 20, pin 1
KERN: e[32mpc_serial:e[0m card supports up to 2 ports
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/ports/pc_serialIt is presumed that you have received the single serial port card and that this has solved the issue?
I remember hearing about one story about diagnosing intermittent issues at Be Inc. I am uncertain how much is fact and how much is folklore, and who was the developer involved (Dominic Giampaolo, Cyril Meurillon, or Benoit Schillings) as it was related to file systems.
As it goes, some file system related code was being debugged using a floppy drive. The code would would run for hours and suddenly crash for apparently no reasons and without clues left. In an attempt to figure it out, the heroic developer stayed up all night by the machine running the code. And it ran, and ran, and run until at dawn the sun shone onto the floppy drive. It so happened that the sun rays caused the media detection sensor to signal that there was no floppy present in the system.
So, finding out the origin of an intermittent fault is a combination of luck and timing - being capable of observing the fault occurring.
It appears that, if solved, this issue will likely become a story which will be remembered for a long time.
3 Likes
No, I just got the single port card this morning. It has run flawlessly for over 48 hours now. Switching to the serial port card has helped. I have had less problems with it and fixing it has taken less time when I have had the problem. I did discover one of the causes in a similar fashion. It would reset or restart at midnight 2-3 times a week. This would cause it to stop seeing the switcher. I saw that happen once and solved that problem.
2 Likes
Glad to hear that the issue has been resolved.
It looks like Tune Tracker needs some refinements to their QA/QC of the packaged systems before they are sent out to customers.
The “midnight restart/reset”, even if now solved, would be an interesting story to hear about.
It had something to do with Steadycast. I saw it a few times when resetting the computer after it would “lose” the switcher. Command Center would come up, and then a few seconds later, it would restart. I would see a box appear, but never really paid attention to it. When I did, it said something like Steadycast didn’t “hear” or “see” something and restarted. This reset everything, including the hot keys at the bottom. I would notice before, that on the days when it was not working, the hot keys had reset.(I would leave them where I could test the switcher relay.) Apparently, this was happening at midnight when the day changed. Not every night, just every 2-3 days. Dane told me how to remove Steadycast, and the midnight mystery ended!