|
I know this has probably already been discussed to the point of exhaustion but I cant find anything that speaks to this issue. The problem that I am having is that my Crosspoint has stopped working. I have 2 iPads and 2 TSW-750's in the system and everything else works but the signals that are distributed via the crosspoint function. Can anyone give me some type of direction with respect to this? I have a feeling it has something to do with the TSW-750's.
Thanks,
DAVE
|
Are you having trouble with getting them to talk (which has been covered to exhaustion) or are you experiencing a failure of connection? I've experienced a couple of random crosspoint disconnects in a system. It's running on a CP3, and it's a crosspoint that is designed to only connect at program start and never change. I've had it happen twice that I'm aware of. Signals just stop coming out of an ECROSS. What I'm doing to trace it down: I put a user event logger along side each of these crosspoints, and I fed the connection$ from the crosspoint into it. Next time the client calls and says "room x doesn't have sound", I can check the log just to make sure that something isn't accidentally breaking the connection by attaching to it. Hopefully I'll decode what it is. I can't find anything in my program that should allow this to happen, but since some of my crosspoint IDs are computed with ASUM and such, there might be a little mistake. I'm pretty confident that it's actually a bug, but I won't waste additional time chasing it after the next hiccup. I'll just make it reconnect every time a zone comes alive or... Heath On Apr 23, 2013, at 5:08 PM, innoventgroup <innoventgroup@...> wrote: I know this has probably already been discussed to the point of exhaustion but I cant find anything that speaks to this issue. The problem that I am having is that my Crosspoint has stopped working. I have 2 iPads and 2 TSW-750's in the system and everything else works but the signals that are distributed via the crosspoint function. Can anyone give me some type of direction with respect to this? I have a feeling it has something to do with the TSW-750's.
Thanks,
DAVE
[Non-text portions of this message have been removed]
|
Hey Heath,
Here is what is happening, I have a tried and true structure for my programing which uses a simple crosspoint configuration. I have 4 rooms and 5 sources. Any of the rooms can view any of the sources. The actual switching of the Audio and Video is done outside of the crosspoint but the control signals for the sources are what is passed through. The system was working just fine when I left it but they had a power outage and when the unit came back up, the crosspoint didn't work. Now here is the weird part, after about 15 minutes, it started working again. So, being the typical tech, I tried to break it again by causing a power outage and, when the system came back up, the crosspoint was indeed busted. The problem is, it never came back this time. I had this problem once before but it was being caused by one of the TPMC-4X units. That is why I think it may be the TSW-750's.
DAVE
toggle quoted message
Show quoted text
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
Are you having trouble with getting them to talk (which has been covered to exhaustion) or are you experiencing a failure of connection?
I've experienced a couple of random crosspoint disconnects in a system. It's running on a CP3, and it's a crosspoint that is designed to only connect at program start and never change. I've had it happen twice that I'm aware of. Signals just stop coming out of an ECROSS.
What I'm doing to trace it down: I put a user event logger along side each of these crosspoints, and I fed the connection$ from the crosspoint into it. Next time the client calls and says "room x doesn't have sound", I can check the log just to make sure that something isn't accidentally breaking the connection by attaching to it. Hopefully I'll decode what it is. I can't find anything in my program that should allow this to happen, but since some of my crosspoint IDs are computed with ASUM and such, there might be a little mistake.
I'm pretty confident that it's actually a bug, but I won't waste additional time chasing it after the next hiccup. I'll just make it reconnect every time a zone comes alive or...
Heath
On Apr 23, 2013, at 5:08 PM, innoventgroup <innoventgroup@...> wrote:
I know this has probably already been discussed to the point of exhaustion but I cant find anything that speaks to this issue. The problem that I am having is that my Crosspoint has stopped working. I have 2 iPads and 2 TSW-750's in the system and everything else works but the signals that are distributed via the crosspoint function. Can anyone give me some type of direction with respect to this? I have a feeling it has something to do with the TSW-750's.
Thanks,
DAVE
[Non-text portions of this message have been removed]
|
I wouldn't think that the TP would have anything to do with it. They are independent things, but you never know ;-) Put a signal name on the connection$ output from the C/Ecrosses and use debugger to see what they are connected to (you'll have to do some decoding and hex conversion. View the string as hex chars in debugger.) The help file describes the structure of that string pretty well. What type of logic do you have making these connections at startup? How about when switching? Crosspoints are things that don't like starting at the very start of program execution. I usually wait some arbitrary amount of time before firing up startup crosspoints (restored from RAM, statically routed). On Apr 23, 2013, at 6:01 PM, "innoventgroup" <innoventgroup@...> wrote: Hey Heath,
Here is what is happening, I have a tried and true structure for my programing which uses a simple crosspoint configuration. I have 4 rooms and 5 sources. Any of the rooms can view any of the sources. The actual switching of the Audio and Video is done outside of the crosspoint but the control signals for the sources are what is passed through. The system was working just fine when I left it but they had a power outage and when the unit came back up, the crosspoint didn't work. Now here is the weird part, after about 15 minutes, it started working again. So, being the typical tech, I tried to break it again by causing a power outage and, when the system came back up, the crosspoint was indeed busted. The problem is, it never came back this time. I had this problem once before but it was being caused by one of the TPMC-4X units. That is why I think it may be the TSW-750's.
DAVE
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
Are you having trouble with getting them to talk (which has been covered to exhaustion) or are you experiencing a failure of connection?
I've experienced a couple of random crosspoint disconnects in a system. It's running on a CP3, and it's a crosspoint that is designed to only connect at program start and never change. I've had it happen twice that I'm aware of. Signals just stop coming out of an ECROSS.
What I'm doing to trace it down: I put a user event logger along side each of these crosspoints, and I fed the connection$ from the crosspoint into it. Next time the client calls and says "room x doesn't have sound", I can check the log just to make sure that something isn't accidentally breaking the connection by attaching to it. Hopefully I'll decode what it is. I can't find anything in my program that should allow this to happen, but since some of my crosspoint IDs are computed with ASUM and such, there might be a little mistake.
I'm pretty confident that it's actually a bug, but I won't waste additional time chasing it after the next hiccup. I'll just make it reconnect every time a zone comes alive or...
Heath
On Apr 23, 2013, at 5:08 PM, innoventgroup <innoventgroup@...> wrote:
I know this has probably already been discussed to the point of exhaustion but I cant find anything that speaks to this issue. The problem that I am having is that my Crosspoint has stopped working. I have 2 iPads and 2 TSW-750's in the system and everything else works but the signals that are distributed via the crosspoint function. Can anyone give me some type of direction with respect to this? I have a feeling it has something to do with the TSW-750's.
Thanks,
DAVE
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
You can also use the routesymstat command in the command prompt window in toolbox to get a full dump of all your xpoint connections. I find it very useful for debugging xpoint issues.
Jay
toggle quoted message
Show quoted text
----- Original Message ----- From: "Heath Volmer" <hvolmer@...> To: Crestron@... Sent: Tuesday, April 23, 2013 7:17:45 PM Subject: Re: [Crestron] Re: Crosspoint has stopped functioning I wouldn't think that the TP would have anything to do with it. They are independent things, but you never know ;-) Put a signal name on the connection$ output from the C/Ecrosses and use debugger to see what they are connected to (you'll have to do some decoding and hex conversion. View the string as hex chars in debugger.) The help file describes the structure of that string pretty well. What type of logic do you have making these connections at startup? How about when switching? Crosspoints are things that don't like starting at the very start of program execution. I usually wait some arbitrary amount of time before firing up startup crosspoints (restored from RAM, statically routed). On Apr 23, 2013, at 6:01 PM, "innoventgroup" <innoventgroup@...> wrote: Hey Heath,
Here is what is happening, I have a tried and true structure for my programing which uses a simple crosspoint configuration. I have 4 rooms and 5 sources. Any of the rooms can view any of the sources. The actual switching of the Audio and Video is done outside of the crosspoint but the control signals for the sources are what is passed through. The system was working just fine when I left it but they had a power outage and when the unit came back up, the crosspoint didn't work. Now here is the weird part, after about 15 minutes, it started working again. So, being the typical tech, I tried to break it again by causing a power outage and, when the system came back up, the crosspoint was indeed busted. The problem is, it never came back this time. I had this problem once before but it was being caused by one of the TPMC-4X units. That is why I think it may be the TSW-750's.
DAVE
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
Are you having trouble with getting them to talk (which has been covered to exhaustion) or are you experiencing a failure of connection?
I've experienced a couple of random crosspoint disconnects in a system. It's running on a CP3, and it's a crosspoint that is designed to only connect at program start and never change. I've had it happen twice that I'm aware of. Signals just stop coming out of an ECROSS.
What I'm doing to trace it down: I put a user event logger along side each of these crosspoints, and I fed the connection$ from the crosspoint into it. Next time the client calls and says "room x doesn't have sound", I can check the log just to make sure that something isn't accidentally breaking the connection by attaching to it. Hopefully I'll decode what it is. I can't find anything in my program that should allow this to happen, but since some of my crosspoint IDs are computed with ASUM and such, there might be a little mistake.
I'm pretty confident that it's actually a bug, but I won't waste additional time chasing it after the next hiccup. I'll just make it reconnect every time a zone comes alive or...
Heath
On Apr 23, 2013, at 5:08 PM, innoventgroup <innoventgroup@...> wrote:
I know this has probably already been discussed to the point of exhaustion but I cant find anything that speaks to this issue. The problem that I am having is that my Crosspoint has stopped working. I have 2 iPads and 2 TSW-750's in the system and everything else works but the signals that are distributed via the crosspoint function. Can anyone give me some type of direction with respect to this? I have a feeling it has something to do with the TSW-750's.
Thanks,
DAVE
------------------------------------ Check out the Files area for useful modules, documents, and drivers. A contact list of Crestron dealers and programmers can be found in the Database area. Yahoo! Groups Links
|
Not a solution by any means, but don't forget about the ROUTESYMSTAT console command. This will tell you what's connected to what. At least you can then see if the processor is even attempting to route your signals.
We've only come across xpoint problems once (and we use them a LOT), when the initialisation xpoint states weren't "taking" but this was a mentally overloaded system that - in theory (and in practice in some areas!) - shouldn't have worked anyway :)
Good luck,
Ol
toggle quoted message
Show quoted text
--- In Crestron@..., "innoventgroup" <innoventgroup@...> wrote:
I know this has probably already been discussed to the point of exhaustion but I cant find anything that speaks to this issue. The problem that I am having is that my Crosspoint has stopped working. I have 2 iPads and 2 TSW-750's in the system and everything else works but the signals that are distributed via the crosspoint function. Can anyone give me some type of direction with respect to this? I have a feeling it has something to do with the TSW-750's.
Thanks,
DAVE
|
Now why is it that when I talk to various high levels of tech support about this problem, nobody suggests that particular command???!!!
Thanks, Jay
toggle quoted message
Show quoted text
On Apr 23, 2013, at 9:00 PM, Jay Basen <jay.m.basen@...> wrote: You can also use the routesymstat command in the command prompt window in toolbox to get a full dump of all your xpoint connections. I find it very useful for debugging xpoint issues.
|
Hey Everyone,
Ok, I am about to blow your mind. It was the TWS-750's. As soon as I updated the firmware to 32, all is well. Just FYI.
Thanks again for all the suggestions.
DAVE
toggle quoted message
Show quoted text
--- In Crestron@..., "olly_penguin" <oliver.hall@...> wrote:
Not a solution by any means, but don't forget about the ROUTESYMSTAT console command. This will tell you what's connected to what. At least you can then see if the processor is even attempting to route your signals.
We've only come across xpoint problems once (and we use them a LOT), when the initialisation xpoint states weren't "taking" but this was a mentally overloaded system that - in theory (and in practice in some areas!) - shouldn't have worked anyway :)
Good luck,
Ol
--- In Crestron@..., "innoventgroup" <innoventgroup@> wrote:
I know this has probably already been discussed to the point of exhaustion but I cant find anything that speaks to this issue. The problem that I am having is that my Crosspoint has stopped working. I have 2 iPads and 2 TSW-750's in the system and everything else works but the signals that are distributed via the crosspoint function. Can anyone give me some type of direction with respect to this? I have a feeling it has something to do with the TSW-750's.
Thanks,
DAVE
|
Do you have any way of knowing that for sure?
toggle quoted message
Show quoted text
On Apr 25, 2013, at 7:04 PM, innoventgroup <innoventgroup@...> wrote: Hey Everyone,
Ok, I am about to blow your mind. It was the TWS-750's. As soon as I updated the firmware to 32, all is well. Just FYI.
Thanks again for all the suggestions.
DAVE
|
Actually, no... in the true scientific world I would not be able to prove it. But I can tell you that it was broke just before I updated the firmware and it was fixed just after... but that is just about as scientific as I can get.
DAVE
toggle quoted message
Show quoted text
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
Do you have any way of knowing that for sure?
On Apr 25, 2013, at 7:04 PM, innoventgroup <innoventgroup@...> wrote:
Hey Everyone,
Ok, I am about to blow your mind. It was the TWS-750's. As soon as I updated the firmware to 32, all is well. Just FYI.
Thanks again for all the suggestions.
DAVE
[Non-text portions of this message have been removed]
|
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it... On 2013-04-25, at 7:30 PM, "innoventgroup" <innoventgroup@...> wrote: Actually, no... in the true scientific world I would not be able to prove it. But I can tell you that it was broke just before I updated the firmware and it was fixed just after... but that is just about as scientific as I can get.
DAVE
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
Do you have any way of knowing that for sure?
On Apr 25, 2013, at 7:04 PM, innoventgroup <innoventgroup@...> wrote:
Hey Everyone,
Ok, I am about to blow your mind. It was the TWS-750's. As soon as I updated the firmware to 32, all is well. Just FYI.
Thanks again for all the suggestions.
DAVE
[Non-text portions of this message have been removed]
|
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@...> wrote: My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots! Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day... Heath
|
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
toggle quoted message
Show quoted text
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@...> wrote: On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@...> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
|
Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
toggle quoted message
Show quoted text
--- In Crestron@..., Neil Dorin <neildorin@...> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@...> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@...> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
Band-aid: PERIODICREBOOT ON There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen. Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks. On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@...> wrote: Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
--- In Crestron@..., Neil Dorin <neildorin@...> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@...> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@...> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
Awesome, thanks Heath and yes I will most definitely report it...
toggle quoted message
Show quoted text
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
Band-aid: PERIODICREBOOT ON
There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen.
Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks.
On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@...> wrote:
Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
--- In Crestron@..., Neil Dorin <neildorin@> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
Hey Heath,
Update on the TSW-750. After hours and hours of messing with the thing and rebooting until my eyes crossed, I was able to isolate the issue down to a Embedded Video object that was pointed at a AXIS M7001 streamer which was connected to a security cam. This configuration worked for several weeks but, has completely died and, is the sole culprit in the whole Crosspoint issue. This conclusion I was actually able to prove. Basically, I can run the whole system without issue right up until I do a page flip to the page that has the the Embedded Video object on it. Then it kills the whole sysem. I can disconnect the Ethernet cable from the TSW-750 and then reconnect it and everything returns to normal. Then, as long as I stay away from the page with the Embedded Video, all is well. I have included the error file from the TSW-750 for your review. I would appreciate any guidance you might be able to throw my way.
SYSTEM LOG:
1. Notice: nk.exe # 19:32:20 5-06-2013 # User Reboot
2. Notice: nk.exe # 19:32:20 5-06-2013 # System startup: TSW-750 [v1.006.0032 (Feb 25 2013) #0097BD36]
3. Notice: ConsoleServiceCE.exe # 19:32:27 5-06-2013 # Got Security Flag: 0
4. Warning: CRESLOG.exe # 19:32:31 5-06-2013 # CRESLOGMAIN: GetRegistryLogParams - Failed to get LogFileName from Registry, set to default
5. Notice: DisplayManager.exe # 19:32:35 5-06-2013 # DisplayManager.exe File Version: 1.0.4805.34895
6. Notice: CrestronVoipApp.exe # 19:32:40 5-06-2013 # VOIP::NC: LOG=Initializing...
7. Notice: CrestronMPEGApp.exe # 19:32:56 5-06-2013 # H264:DestroyMPEGApplication: DONE!
8. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # Device ID=3E
9. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # LCD color depth is 18
10. Error: CmXFlash_CE.exe # 19:41:01 5-06-2013 # ERROR: 07:41:01.000 All Pages loaded... No more background loading.Total/Private/Free 92430336/22835200/380928
11. Error: CrestronMPEGApp.exe # 18:50:30 5-07-2013 # ERROR:unable to find multicast source address
12. Error: DisplayManager.exe # 18:50:30 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
13. Error: CrestronMPEGApp.exe # 19:12:07 5-07-2013 # ERROR:unable to find multicast source address
14. Error: DisplayManager.exe # 19:12:07 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
15. Notice: ConsoleServiceCE.exe # 19:14:51 5-07-2013 # CTP Connection from: 192.168.0.115
Total Msgs Logged = 56
END OF SYSTEM LOG
Thanks in advance,
DAVE
toggle quoted message
Show quoted text
--- In Crestron@..., "innoventgroup" <innoventgroup@...> wrote:
Awesome, thanks Heath and yes I will most definitely report it...
--- In Crestron@..., Heath Volmer <hvolmer@> wrote:
Band-aid: PERIODICREBOOT ON
There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen.
Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks.
On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@> wrote:
Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
--- In Crestron@..., Neil Dorin <neildorin@> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
whoops... I just re-read my post and realized it should have said "and, is the sole REMAINING culprit in the whole Crosspoint issue."
toggle quoted message
Show quoted text
--- In Crestron@..., "innoventgroup" <innoventgroup@...> wrote:
Hey Heath,
Update on the TSW-750. After hours and hours of messing with the thing and rebooting until my eyes crossed, I was able to isolate the issue down to a Embedded Video object that was pointed at a AXIS M7001 streamer which was connected to a security cam. This configuration worked for several weeks but, has completely died and, is the sole culprit in the whole Crosspoint issue. This conclusion I was actually able to prove. Basically, I can run the whole system without issue right up until I do a page flip to the page that has the the Embedded Video object on it. Then it kills the whole sysem. I can disconnect the Ethernet cable from the TSW-750 and then reconnect it and everything returns to normal. Then, as long as I stay away from the page with the Embedded Video, all is well. I have included the error file from the TSW-750 for your review. I would appreciate any guidance you might be able to throw my way.
SYSTEM LOG:
1. Notice: nk.exe # 19:32:20 5-06-2013 # User Reboot
2. Notice: nk.exe # 19:32:20 5-06-2013 # System startup: TSW-750 [v1.006.0032 (Feb 25 2013) #0097BD36]
3. Notice: ConsoleServiceCE.exe # 19:32:27 5-06-2013 # Got Security Flag: 0
4. Warning: CRESLOG.exe # 19:32:31 5-06-2013 # CRESLOGMAIN: GetRegistryLogParams - Failed to get LogFileName from Registry, set to default
5. Notice: DisplayManager.exe # 19:32:35 5-06-2013 # DisplayManager.exe File Version: 1.0.4805.34895
6. Notice: CrestronVoipApp.exe # 19:32:40 5-06-2013 # VOIP::NC: LOG=Initializing...
7. Notice: CrestronMPEGApp.exe # 19:32:56 5-06-2013 # H264:DestroyMPEGApplication: DONE!
8. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # Device ID=3E
9. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # LCD color depth is 18
10. Error: CmXFlash_CE.exe # 19:41:01 5-06-2013 # ERROR: 07:41:01.000 All Pages loaded... No more background loading.Total/Private/Free 92430336/22835200/380928
11. Error: CrestronMPEGApp.exe # 18:50:30 5-07-2013 # ERROR:unable to find multicast source address
12. Error: DisplayManager.exe # 18:50:30 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
13. Error: CrestronMPEGApp.exe # 19:12:07 5-07-2013 # ERROR:unable to find multicast source address
14. Error: DisplayManager.exe # 19:12:07 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
15. Notice: ConsoleServiceCE.exe # 19:14:51 5-07-2013 # CTP Connection from: 192.168.0.115
Total Msgs Logged = 56
END OF SYSTEM LOG
Thanks in advance,
DAVE
--- In Crestron@..., "innoventgroup" <innoventgroup@> wrote:
Awesome, thanks Heath and yes I will most definitely report it...
--- In Crestron@..., Heath Volmer <hvolmer@> wrote:
Band-aid: PERIODICREBOOT ON
There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen.
Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks.
On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@> wrote:
Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
--- In Crestron@..., Neil Dorin <neildorin@> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
I'm glad you isolated it. I'm afraid I'm not the one to read the error log and tell you anything - especially why it should knock out a TSW. What are the URLs you're using to connect? I know with the NVS-200 there are RTSP urls. Not sure about the Axis... Heath On May 8, 2013, at 4:26 PM, "innoventgroup" <innoventgroup@...> wrote: whoops... I just re-read my post and realized it should have said "and, is the sole REMAINING culprit in the whole Crosspoint issue."
--- In Crestron@..., "innoventgroup" <innoventgroup@...> wrote:
Hey Heath,
Update on the TSW-750. After hours and hours of messing with the thing and rebooting until my eyes crossed, I was able to isolate the issue down to a Embedded Video object that was pointed at a AXIS M7001 streamer which was connected to a security cam. This configuration worked for several weeks but, has completely died and, is the sole culprit in the whole Crosspoint issue. This conclusion I was actually able to prove. Basically, I can run the whole system without issue right up until I do a page flip to the page that has the the Embedded Video object on it. Then it kills the whole sysem. I can disconnect the Ethernet cable from the TSW-750 and then reconnect it and everything returns to normal. Then, as long as I stay away from the page with the Embedded Video, all is well. I have included the error file from the TSW-750 for your review. I would appreciate any guidance you might be able to throw my way.
SYSTEM LOG:
1. Notice: nk.exe # 19:32:20 5-06-2013 # User Reboot
2. Notice: nk.exe # 19:32:20 5-06-2013 # System startup: TSW-750 [v1.006.0032 (Feb 25 2013) #0097BD36]
3. Notice: ConsoleServiceCE.exe # 19:32:27 5-06-2013 # Got Security Flag: 0
4. Warning: CRESLOG.exe # 19:32:31 5-06-2013 # CRESLOGMAIN: GetRegistryLogParams - Failed to get LogFileName from Registry, set to default
5. Notice: DisplayManager.exe # 19:32:35 5-06-2013 # DisplayManager.exe File Version: 1.0.4805.34895
6. Notice: CrestronVoipApp.exe # 19:32:40 5-06-2013 # VOIP::NC: LOG=Initializing...
7. Notice: CrestronMPEGApp.exe # 19:32:56 5-06-2013 # H264:DestroyMPEGApplication: DONE!
8. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # Device ID=3E
9. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # LCD color depth is 18
10. Error: CmXFlash_CE.exe # 19:41:01 5-06-2013 # ERROR: 07:41:01.000 All Pages loaded... No more background loading.Total/Private/Free 92430336/22835200/380928
11. Error: CrestronMPEGApp.exe # 18:50:30 5-07-2013 # ERROR:unable to find multicast source address
12. Error: DisplayManager.exe # 18:50:30 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
13. Error: CrestronMPEGApp.exe # 19:12:07 5-07-2013 # ERROR:unable to find multicast source address
14. Error: DisplayManager.exe # 19:12:07 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
15. Notice: ConsoleServiceCE.exe # 19:14:51 5-07-2013 # CTP Connection from: 192.168.0.115
Total Msgs Logged = 56
END OF SYSTEM LOG
Thanks in advance,
DAVE
--- In Crestron@..., "innoventgroup" <innoventgroup@> wrote:
Awesome, thanks Heath and yes I will most definitely report it...
--- In Crestron@..., Heath Volmer <hvolmer@> wrote:
Band-aid: PERIODICREBOOT ON
There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen.
Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks.
On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@> wrote:
Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
--- In Crestron@..., Neil Dorin <neildorin@> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
Hey Heath,
I finally got to the customers site and updated the panels to look at the RTSP instead of the HTTP and Dude... you are a genius... that fixed it. Thanks!!
DAVE
toggle quoted message
Show quoted text
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
I'm glad you isolated it. I'm afraid I'm not the one to read the error log and tell you anything - especially why it should knock out a TSW.
What are the URLs you're using to connect? I know with the NVS-200 there are RTSP urls. Not sure about the Axis...
Heath
On May 8, 2013, at 4:26 PM, "innoventgroup" <innoventgroup@...> wrote:
whoops... I just re-read my post and realized it should have said "and, is the sole REMAINING culprit in the whole Crosspoint issue."
--- In Crestron@..., "innoventgroup" <innoventgroup@> wrote:
Hey Heath,
Update on the TSW-750. After hours and hours of messing with the thing and rebooting until my eyes crossed, I was able to isolate the issue down to a Embedded Video object that was pointed at a AXIS M7001 streamer which was connected to a security cam. This configuration worked for several weeks but, has completely died and, is the sole culprit in the whole Crosspoint issue. This conclusion I was actually able to prove. Basically, I can run the whole system without issue right up until I do a page flip to the page that has the the Embedded Video object on it. Then it kills the whole sysem. I can disconnect the Ethernet cable from the TSW-750 and then reconnect it and everything returns to normal. Then, as long as I stay away from the page with the Embedded Video, all is well. I have included the error file from the TSW-750 for your review. I would appreciate any guidance you might be able to throw my way.
SYSTEM LOG:
1. Notice: nk.exe # 19:32:20 5-06-2013 # User Reboot
2. Notice: nk.exe # 19:32:20 5-06-2013 # System startup: TSW-750 [v1.006.0032 (Feb 25 2013) #0097BD36]
3. Notice: ConsoleServiceCE.exe # 19:32:27 5-06-2013 # Got Security Flag: 0
4. Warning: CRESLOG.exe # 19:32:31 5-06-2013 # CRESLOGMAIN: GetRegistryLogParams - Failed to get LogFileName from Registry, set to default
5. Notice: DisplayManager.exe # 19:32:35 5-06-2013 # DisplayManager.exe File Version: 1.0.4805.34895
6. Notice: CrestronVoipApp.exe # 19:32:40 5-06-2013 # VOIP::NC: LOG=Initializing...
7. Notice: CrestronMPEGApp.exe # 19:32:56 5-06-2013 # H264:DestroyMPEGApplication: DONE!
8. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # Device ID=3E
9. Notice: CmXFlash_CE.exe # 19:32:57 5-06-2013 # LCD color depth is 18
10. Error: CmXFlash_CE.exe # 19:41:01 5-06-2013 # ERROR: 07:41:01.000 All Pages loaded... No more background loading.Total/Private/Free 92430336/22835200/380928
11. Error: CrestronMPEGApp.exe # 18:50:30 5-07-2013 # ERROR:unable to find multicast source address
12. Error: DisplayManager.exe # 18:50:30 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
13. Error: CrestronMPEGApp.exe # 19:12:07 5-07-2013 # ERROR:unable to find multicast source address
14. Error: DisplayManager.exe # 19:12:07 5-07-2013 # TSXPlatform: H264: Video stream failed to open!
15. Notice: ConsoleServiceCE.exe # 19:14:51 5-07-2013 # CTP Connection from: 192.168.0.115
Total Msgs Logged = 56
END OF SYSTEM LOG
Thanks in advance,
DAVE
--- In Crestron@..., "innoventgroup" <innoventgroup@> wrote:
Awesome, thanks Heath and yes I will most definitely report it...
--- In Crestron@..., Heath Volmer <hvolmer@> wrote:
Band-aid: PERIODICREBOOT ON
There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen.
Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks.
On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@> wrote:
Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
--- In Crestron@..., Neil Dorin <neildorin@> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
