4.1.10 crashes

[AtariJeff]

Just wondering if this is happening to anyone else. Since upgrading to 4.1.10 I get a random crash about once every two days. No error message, the app just just drops out and I'm staring at the desktop. Last time was when I was navigating through the recordings list

[ToxMox]

Same here. I've turned on debug logging to hopefully get a log for the next time it happens.

[jlabrue]

Ditto for me. I had another incident that happened to me last night and I sent a bug report in. I was watching a previously recorded show and midway throough it I had 4 things set to start recording. At the precise time that they werestarting the service crashed and restarted so I lost the first 3 minutes of all of them. Fortunately it picked up recording after the service restarted but I then has to restart the GUI.

[AtariJeff]

This crash is on my main client. Come to think of it I think I have debugging already turned on. I'll submit a bug report tonight with logs attached.

[Polypro]

I have one DVD rip that'll crash Sage if you FF/RW...sent in a report w/ logs. I've also had it crash randomly when waking from the tray with either a remote button that's mapped, or double clicking with the mouse.

P

[rickgillyon]

Twice I had Sage just disappear with 4.1.10, and it wrote a crash log. Sage tell me it's Java that crashed, and it could be a bad hdd, ram or java install. I'm going to do a full java reinstall today and check disks and ram...

Anyone know, if I want to switch to service mode from normal mode, do I just copy sage.properties to sageclient.properties before starting the service?

[Opus4]

Originally Posted by rickgillyon

Anyone know, if I want to switch to service mode from normal mode, do I just copy sage.properties to sageclient.properties before starting the service?

I haven't done it in a long time, but I think that if there is no sageclient.properties file (and no autobackup), the pseudo-client will base its initial properties on sage.properties. i.e.: I would just start the service, start the UI w/o any client properties file present, & see what happens. (Oh - and if it doesn't base the client properties on sage.properties, please let me know.)

- Andy

[rickgillyon]

Originally Posted by Opus4

I haven't done it in a long time, but I think that if there is no sageclient.properties file (and no autobackup), the pseudo-client will base its initial properties on sage.properties. i.e.: I would just start the service, start the UI w/o any client properties file present, & see what happens.

Yep, worked great, thanks. Now using the server headless and running a client anyway (another $30 for Sage!), so the server is (I assume) still using sage.properties. Using a client means that I can run XviD encodes/transcodes on the server, and playback never stutters at all. Brilliant!

[rsagetv99]

Originally Posted by AtariJeff

Just wondering if this is happening to anyone else. Since upgrading to 4.1.10 I get a random crash about once every two days. No error message, the app just just drops out and I'm staring at the desktop. Last time was when I was navigating through the recordings list

This has happened to me a few times as well, anyone submit a bug report?

[bkavanaugh]

I haven't upgraded to 4.1.10 yet (still 4.1.8), but I've been experiencing the same thing since 4.1.6 (I think) - app crashes to the desktop every couple of days. I haven't had time to research the problem, though. I do know I was on the most recent Java VM.

[DavidFeinzeig]

I've had the same problem with 4.1.3 for awhile now. But only on my client machine, not the server. When it crashes there is a PID error log generated, but it is empty. So it seems that it is crashing without getting a chance to write the log. I also have the most recent version of Java.

[rsagetv99]

Originally Posted by bkavanaugh

I haven't upgraded to 4.1.10 yet (still 4.1.8), but I've been experiencing the same thing since 4.1.6 (I think) - app crashes to the desktop every couple of days. I haven't had time to research the problem, though. I do know I was on the most recent Java VM.

Come to think of it, I had the problem back on 4.1.6 too.

[DFA]

Not sure if we are all talking about the same thing but I'm still at 4.1.8 and have experienced the Sage "disappearing act".

It has occurred only about 3 times and long in between. The first time it occurred, I was doing some other things on the machine with Sage in the background and thought that I had inadvertantly closed it. When it happens, nothing appears in the OS event logs to indicate any problem. Since last occurance, I have turned on Sage logging to see if that might give a clue.

However, we have been experiencing other things as well. I have just recently returned from 2 weeks in Oman and the wife had a laundry list of complaints (I was dumb enough to install 4.1.8 not long before my departure):

1. Occassional failure to respond to any remote control commands (Girder; SendMessage). Probably long pause / temporary hang thing.

2. HTPC sometimes will not wake from S3 sleep by USB-UIRT IR command. Requires a push of front panel button to wake up. This I observed once before my departure and twice since my return. This has always worked without fail in the past.

3. I have an IR emitter that goes to DLP on zone 2 of USB-UIRT that has only one function: On scheduled event of 1:00 AM, put Sage in sleep AND turn the TV off to save me from being rudely awakened by my better half when I have zonked out on the couch. According to reports I have gotten, the TV has turned off for no apparent reason when she has been watching it (she thinks something is wrong with the TV). However, that translates to me as a misfire from Girder / USB-UIRT for some reason. Although this seems like Sage could have nothing to do with this, this all started with 4.1.6/8. On the oher hand, I was not entirely clear about it and knowing better than to pursue the details, it may have just been the Sage "disappearing act" that she meant.

I am now pondering wether to move on to 4.1.10 or roll back to 4.1.3.67 which seemed stable. I will acknowledge that something else may be going on with my system, but there have not been any other significant changes that could account for the general weirdness. I am not taking advantage of "place shifting" at this time.

Now if I can just find some those many posts that talked about rollback procedures. I have the entire 4.1.3.67 directory saved.

EDIT: Noted that there is rollback steps in the sticky for this forum for "Installing new version of Sage". Hey Opus, might want to rename "Installing and rollback procedures for ....."

EDIT EDIT: My remote control problems and reomte wake-up from S3 sleep have proven to be an intermittant failure of my newer "zone" version USB-UIRT. After some testing and substituting an older non-zone USB-UIRT I have had in retirement, the channel change and wake-up problems went away. The Sage "disappearing act" (shut down) problem stands, however. Sorry for adding issues that were not ultimately Sage related.

DFA

[ToxMox]

I'm still having this problem of Sage quitting to the desktop every few days for no reason. I've got every type of logging going on and nothing special is showing up in there except maybe the part about the screen saver timeout...here is an excerpt from my sagetvclient log from right before it ended up on the desktop:This happened while watching a recording and not doing anything at all on the remote.

Sun 4/9 13:54:40.171 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:54:45.172 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:54:50.173 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:54:55.173 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:00.173 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:05.174 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:10.174 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:15.174 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:20.174 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:25.175 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:30.175 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:35.175 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:40.175 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:45.176 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:50.179 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:55:55.179 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:00.179 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:04.881 VF processing job null nPlayin=true
Sun 4/9 13:56:04.881 isRec=false rd=3657664 base=431613
Sun 4/9 13:56:04.890 VF thread is now waiting for 0:53:45.790
Sun 4/9 13:56:05.180 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:10.180 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:15.180 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:20.181 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:25.181 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:30.181 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:33.737 Screen Saver Timeout expired....tv=true playin=true fs=true sleepy=false currSS=false
Sun 4/9 13:56:35.181 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:40.182 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:45.182 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:50.182 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:56:55.182 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:57:00.183 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:57:05.183 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:57:10.183 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:57:15.183 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:57:20.184 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:57:25.184 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]
Sun 4/9 13:57:30.184 Received command of:NOOP from Socket[addr=/127.0.0.1,port=42024,localport=1721]

[rickgillyon]

I'm not a Sage techie, but my guess is that the NOOPs are standard timeouts occurring when there's no processing to be done. I see it all the time in my logs with no problem at all...

[ToxMox]

Originally Posted by rickgillyon

I'm not a Sage techie, but my guess is that the NOOPs are standard timeouts occurring when there's no processing to be done. I see it all the time in my logs with no problem at all...

Originally Posted by ToxMox

nothing special is showing up in there except maybe the part about the screen saver timeout

I wasn't referring to the NOOPs...I included them for reference.

[rickgillyon]

That'll reach me to actually read what you say rather than just read the log...

As you say, doesn't look like the log has anything of interest. The crash I had was the same, nothing in the log of interest at all...hasn't happened with 4.1.12 though.

[ToxMox]

Happened to me twice so far with 4.1.12

[rickgillyon]

Is your client on the same machine as the server?

[ToxMox]

Yup.