SagetvMiniClient Crashing....on ShieldTV.

[nyplayer]

Since the latest release of the Windows Sage ... The MiniClient when going into Videos Folders it crashes.... Running on my ShieldTV.

log attached.... see bottom of the log.

[stuckless]

Originally Posted by nyplayer

Since the latest release of the Windows Sage ... The MiniClient when going into Videos Folders it crashes.... Running on my ShieldTV.

log attached.... see bottom of the log.

Are you able to test using a placeshifter? Just trying to narrow down if this is an Android issue or a server issue?

[nyplayer]

Originally Posted by stuckless

Are you able to test using a placeshifter? Just trying to narrow down if this is an Android issue or a server issue?

Yes I can will post back.

[nyplayer]

Update it works on PlaceShifter.

[stuckless]

Originally Posted by nyplayer

Update it works on PlaceShifter.

That's good to know... we can focus on Android... Sadly, though, that going to make it harder Google has locked down the log file access, so it's pretty hard to get logs on an android device.

When it crashes, do you get the option to send a crash report? If so, do that, and it will send me the logs.

I see some tools like this..
https://play.google.com/store/apps/d...rg.jtb.alogrec
That appear to redirect the logcat output to the sdcard, not sure if that can help us get the logs or not. But somehow, we'll need to get the logging info.

The MiniClient has a settings option to write the log to sdard, but that's only helpful if I'm catching the and logging the error, which in this case, I'm not (since it's crashing)

[nyplayer]

Originally Posted by stuckless

That's good to know... we can focus on Android... Sadly, though, that going to make it harder Google has locked down the log file access, so it's pretty hard to get logs on an android device.

When it crashes, do you get the option to send a crash report? If so, do that, and it will send me the logs.

I see some tools like this..
https://play.google.com/store/apps/d...rg.jtb.alogrec
That appear to redirect the logcat output to the sdcard, not sure if that can help us get the logs or not. But somehow, we'll need to get the logging info.

The MiniClient has a settings option to write the log to sdard, but that's only helpful if I'm catching the and logging the error, which in this case, I'm not (since it's crashing)

This is the log from the miniClient.

[stuckless]

Originally Posted by nyplayer

This is the log from the miniClient.

You have hit this issue
https://github.com/OpenSageTV/sagetv...ient/issues/73

sagetv gives me a filename in which to cache the image from the server... this filename is too large for android, and I'll need to find another caching strategy. I just don't know of a good reliable strategy, yet. I open to suggestions. I can use a hash, but a hash may result in collisions

In your case the image filename is...

file-C3a5cProgram20Files2028x86295cSageTV5cSageTV5cGeneratedThumbnails5cNAS2dBE2dB82d48backupVIDEOSAdventures20of20Superman20195220Complete20SeriesAdventures20of20Superman20Season202Adventures20of20Superman202d202x01202d20Five20Minutes20To20Doomavi2ejpg-1498275906000-512-384

[KarylFStein]

Originally Posted by stuckless

You have hit this issue
https://github.com/OpenSageTV/sagetv...ient/issues/73

sagetv gives me a filename in which to cache the image from the server... this filename is too large for android, and I'll need to find another caching strategy. I just don't know of a good reliable strategy, yet. I open to suggestions. I can use a hash, but a hash may result in collisions

In your case the image filename is...

file-C3a5cProgram20Files2028x86295cSageTV5cSageTV5cGeneratedThumbnails5cNAS2dBE2dB82d48backupVIDEOSAdventures20of20Superman20195220Complete20SeriesAdventures20of20Superman20Season202Adventures20of20Superman202d202x01202d20Five20Minutes20To20Doomavi2ejpg-1498275906000-512-384

Would a quick fix be to just not cache files with too long a name? Or do you need to write the file locally to view?

[stuckless]

Originally Posted by KarylFStein

Would a quick fix be to just not cache files with too long a name? Or do you need to write the file locally to view?

without file caching, you'll see lots of pauses in the UI.

[KarylFStein]

Originally Posted by stuckless

without file caching, you'll see lots of pauses in the UI.

Even if just a couple files can't be cached, or is it all or nothing? I just had this problem with some late night episode names. It does not seem to be a wide issue. In fact I turned recording of late night shows back on after family objections and I haven't seen issues over the past week or two, (which after saying that probably means tonight some recording will cause problems again ).

And I'm just saying as a way to keep the client from crashing until a better solution can be found.

[Taddeusz]

Originally Posted by stuckless

You have hit this issue
https://github.com/OpenSageTV/sagetv...ient/issues/73

sagetv gives me a filename in which to cache the image from the server... this filename is too large for android, and I'll need to find another caching strategy. I just don't know of a good reliable strategy, yet. I open to suggestions. I can use a hash, but a hash may result in collisions

Given the file name length limit I would probably generate a UUID to use as a filename and key for a dictionary and store the name of the file as its value. That way you can easily to a value lookup when a file is requested to check if it is already cached. Using a UUID to identify cached files would not likely generate collisions.

[wayner]

@nyplayer - for now can't you shorten the path of the folder. Currently it is something like (I may have the folder breaks wrong): VIDEOS\Adventures of Superman 1952 Complete Series\Adventures of Superman\Season 2\Adventures of Superman - 2x01 -Five Minutes To Doom.avi

Or will that screw something else up. Even if it was automatically named you should be able to change the name of the folder and it should still work as it is still in your VIDEOS library.

[Taddeusz]

Originally Posted by Taddeusz

Given the file name length limit I would probably generate a UUID to use as a filename and key for a dictionary and store the name of the file as its value. That way you can easily to a value lookup when a file is requested to check if it is already cached. Using a UUID to identify cached files would not likely generate collisions.

And of course store the dictionary in a local sqlite database.

[wnjj]

Originally Posted by stuckless

You have hit this issue
https://github.com/OpenSageTV/sagetv...ient/issues/73

sagetv gives me a filename in which to cache the image from the server... this filename is too large for android, and I'll need to find another caching strategy. I just don't know of a good reliable strategy, yet. I open to suggestions. I can use a hash, but a hash may result in collisions

How about hashing only the long names, cutting way down on the chances for an issue? You could prefix those with some kind of unique word to sort them out from normal ones. Something like "cached-<hash>".

[stuckless]

Originally Posted by Taddeusz

Given the file name length limit I would probably generate a UUID to use as a filename and key for a dictionary and store the name of the file as its value. That way you can easily to a value lookup when a file is requested to check if it is already cached. Using a UUID to identify cached files would not likely generate collisions.

Originally Posted by Taddeusz

And of course store the dictionary in a local sqlite database.

Originally Posted by wnjj

How about hashing only the long names, cutting way down on the chances for an issue? You could prefix those with some kind of unique word to sort them out from normal ones. Something like "cached-<hash>".

I do think hashing will likely be used. It might be that UUID might have a low collision, but, there is still a risk of collisions and the effect of that collision might be disastrous on the UI, but I agree, we might have to live with some amount of collision failure.

I was thinking that maybe using a hash + the last 30chars of the filename. That will create a file that is about 50chars in length and collisions would likely be reduced.

[Taddeusz]

Originally Posted by stuckless

I do think hashing will likely be used. It might be that UUID might have a low collision, but, there is still a risk of collisions and the effect of that collision might be disastrous on the UI, but I agree, we might have to live with some amount of collision failure.

I was thinking that maybe using a hash + the last 30chars of the filename. That will create a file that is about 50chars in length and collisions would likely be reduced.

I don't think you would need to worry about collisions with Java's random UUID generator.

[stuckless]

Originally Posted by Taddeusz

I don't think you would need to worry about collisions with Java's random UUID generator.

Since I would not consider using a database and doing a query for each cached image, I need to ensure that a very large filename ALWAYS creates the same hash/uuid, so in this case, I'd be using the name based UUID (and not random) and likely UUID.fromString(filename). While it's not likely this will result in collisions, collisions can still happen.

Unfortunately, do to other pending requirements, I can't work on this in the next few weeks (I'd be happy to accept a pull request, if someone wanted to give it a try). But, unfortunately, between work and another time sensitive paid side project, it's not leaving a lot of time lately for sagetv