0.6 beta forked - crashing

[ceperry]

I've been playing around with the updated Harmonium code. After a few weeks, I've noticed a pattern with a crashing bug.

If I set it loose to shuffle through my entire library, it will play just fine for an indeterminate ammount of time, usually between 20 and 30 minutes when it will crash. After it crashes, one of two symptoms show up when I restart on the TiVo: either 1) Harmonium will play only a few seconds of music and then crash again, or 2) album art will display, but no music will play. In scenario 2, I can skip through the playlist and the album art will change, but no music will play.

I'm attaching a log file, but here is an excerpt of what seems to be the relevant part of a scenario 1 crash:\

Code: Select all

INFO   | jvm 1    | 2009/10/10 13:22:26 | java.lang.OutOfMemoryError: Java heap space
INFO   | jvm 1    | 2009/10/10 13:22:26 | LOG: HME receiver disconnected
INFO   | jvm 1    | 2009/10/10 13:22:26 | LOG: connection to receiver closed
INFO   | jvm 1    | 2009/10/10 13:22:26 | Exception in thread "Thread-247" com.tivo.hme.sdk.HmeException: Java heap space
INFO   | jvm 1    | 2009/10/10 13:22:26 |    at com.tivo.hme.sdk.Application.fatalError(Application.java:937)
INFO   | jvm 1    | 2009/10/10 13:22:26 |    at com.tivo.hme.sdk.Application.cmdRsrcAddImage(Application.java:1170)
INFO   | jvm 1    | 2009/10/10 13:22:26 |    at com.tivo.hme.sdk.ImageResource$ImageResourceImage.<init>(ImageResource.java:138)
INFO   | jvm 1    | 2009/10/10 13:22:26 |    at com.tivo.hme.sdk.HmeObject.createImage(HmeObject.java:265)
INFO   | jvm 1    | 2009/10/10 13:22:26 |    at org.dazeend.harmonium.screens.HManagedResourceScreen$AlbumArtCache.Add(HManagedResourceScreen.java:192)
INFO   | jvm 1    | 2009/10/10 13:22:26 |    at org.dazeend.harmonium.screens.HManagedResourceScreen.createManagedImage(HManagedResourceScreen.java:91)
INFO   | jvm 1    | 2009/10/10 13:22:26 |    at org.dazeend.harmonium.screens.NowPlayingScreen$1.run(NowPlayingScreen.java:93)


Here's a scenario 2 crash:

Code: Select all

INFO   | jvm 1    | 2009/10/10 14:34:16 | LOG: HME receiver disconnected
INFO   | jvm 1    | 2009/10/10 14:34:16 | Exception in thread "Thread-43" com.tivo.hme.sdk.HmeException: Connection reset by peer: socket write error
INFO   | jvm 1    | 2009/10/10 14:34:16 |    at com.tivo.hme.sdk.Application.fatalError(Application.java:937)
INFO   | jvm 1    | 2009/10/10 14:34:16 |    at com.tivo.hme.sdk.Application.cmdRsrcAddImage(Application.java:1170)
INFO   | jvm 1    | 2009/10/10 14:34:16 |    at com.tivo.hme.sdk.ImageResource$ImageResourceImage.<init>(ImageResource.java:138)
INFO   | jvm 1    | 2009/10/10 14:34:16 |    at com.tivo.hme.sdk.HmeObject.createImage(HmeObject.java:265)
INFO   | jvm 1    | 2009/10/10 14:34:16 |    at org.dazeend.harmonium.screens.HManagedResourceScreen$AlbumArtCache.Add(HManagedResourceScreen.java:192)
INFO   | jvm 1    | 2009/10/10 14:34:16 |    at org.dazeend.harmonium.screens.HManagedResourceScreen.createManagedImage(HManagedResourceScreen.java:91)
INFO   | jvm 1    | 2009/10/10 14:34:16 |    at org.dazeend.harmonium.screens.NowPlayingScreen$2.run(NowPlayingScreen.java:326)
INFO   | jvm 1    | 2009/10/10 14:34:16 | LOG: connection to receiver closed
INFO   | jvm 1    | 2009/10/10 14:34:16 | LOG: 192.168.1.2 I/O Exception handling  HTTP GET Sting/Brand New Day/01 A Thousand Years.mp3: Connection reset by peer: socket write error

It looks like I might be able to correct the Scenario 1 (java.lang.OutOfMemoryError: Java heap space) error by playing around with maximum heap space settings in the wrapper.conf file, but I'm wondering if this is an indicator of an underlying problem in the way we're handling resources. What do you think?

Here's the full log file:

wrapper.log

Harmonium Log File - wrapper.log

(250.67 KiB) Downloaded 14 times

[iolsen]

My instinct is that the default 64MB Java heap size just isn't big enough for you any more. My music collection is big enough that I changed this on my server long ago, because the cache file couldn't even be built.

I doubt it, but it's possible there's something I've done (in the resource management or elsewhere) that's needlessly bloating the heap. My wrapper.conf is set for a 64/256 (initial/max), and I don't have issues. When I get a chance to investigate, I'll say more.

[iolsen]

Reading more closely, I see the heap may not be the only issue. I won't have a chance to dig deeper tonight, but I will this week.

[ceperry]

I'll bump up my resource heap. I assume that will fix the out of memory errors. I'll report back whether it affects the other crash I'm seeing.

[iolsen]

I've been unable to find the culprit for this. In particular, I thought there might be a bug behind your "scenario 2", but now I'm not so sure. Did increasing the heap size make both issues go away?