[McW]

After upgrade to latest version (2.4.27) Zappiti does not show all episodes correctly for many of my shows (everything worked on my old version 2.3.??)

Here is an example:
Season 1 of 'Allo Allo' notice that the pictures for episode 1 and 4 has been replaced by a white folder icon: http://tinypic.com/r/2qrzno2/6

When I look at episode # 4 I get this screen: http://tinypic.com/r/11i067p/6

The files on my NAS are all named s01e01 etc.

Naturally I have tried to delete, rescrape and export but no effect. Everything looks OK on my pc.

My Dune HD Max is running firmware 110606_1315

What to do?

[NtegrA]

Same here on both movies & TV show episodes.

I am getting a bunch of the folder icons like your first screen, non working links like your second screen, and also a lot of my movies won't play from the "synopsis" screen. I have to hit "Play" directly from the movie wall in order to get most things to start.

I am on version 2.4.25.0.... Everything (for the most part) seemed to work properly before upgrading to this version.

[joebel]

Originally Posted by NtegrA Same here on both movies & TV show episodes. I am getting a bunch of the folder icons like your first screen, non working links like your second screen, and also a lot of my movies won't play from the "synopsis" screen. I have to hit "Play" directly from the movie wall in order to get most things to start. I am on version 2.4.25.0.... Everything (for the most part) seemed to work properly before upgrading to this version.

If you look in the Zappiti log file, you see a .Net error concerning the length of the UNC path they are trying to write, which exceeds the supprted length. A known problem when dealing with windows shares through that library.

I had the same problem with 2.4.27.. untill I shortened the share name of the folder I wrote the zappiti files to.

[NtegrA]

Originally Posted by joebel If you look in the Zappiti log file, you see a .Net error concerning the length of the UNC path they are trying to write, which exceeds the supprted length. A known problem when dealing with windows shares through that library. I had the same problem with 2.4.27.. untill I shortened the share name of the folder I wrote the zappiti files to.

Well that's a shame.. seeing that NFS shares appears to have stopped functioning as of this version for me as well!

[joebel]

Originally Posted by NtegrA Well that's a shame.. seeing that NFS shares appears to have stopped functioning as of this version for me as well!

They DO work for me. Are you sure it's not a config problem? Seeing that 2.4.27 now exports a working index (using 3 separate NFS-drives for links to movies and tv-series, and quite some content in there).

[McW]

@joebel

Thanks!

I formatted my harddisk and changed from EXT2 to NTFS because that was the only way i could reduce the share name that I export my Zappiti files to.

Now it seems to work

[Tsingtao]

Is this problem down to the length of the path where the file is stored?

I have a similar issue but with some episodes showing ok an others showing as folders, given these are in the same file in the same location why would Zppiti do this?

[joebel]

Originally Posted by Tsingtao Is this problem down to the length of the path where the file is stored? I have a similar issue but with some episodes showing ok an others showing as folders, given these are in the same file in the same location why would Zppiti do this?

It's the length of the total path Zappiti is writing to, when it's exporting the index. They seem to use a .Net library that has a limitation for writing unc's larger than 256 characters. There are other libraries available that can circumvent this.

[Six66Mike]

I read on the french board they have found a way to trim about 30 characters. (I think that was the figure, can't be bothered reloading Google Translate and verifying).

I'm not sure why we need a hash 40 characters long like 146bd1ec19400e968d6eed3e3ecd16f201c75a47 tagged on to a folder anyway, especially for every sub folder in a TV series. So you end up like this:

Criminal Minds - c2367534b88e8ccdb3c6c6679ff76b81ca40fe1c\001 - c566b41e53abde6cb54f4433925115d208dca708\003- Won't Get Fooled Again - da9e93ece7d8c2c5abb614992f5bb7f9fdf615ac

iTunes makes a short hash, same with YouTube, Bit.Ly and nearly any URL shortening service. We don't need 40 character hashes in Zappiti either.

[Tsingtao]

Any idea how they managed to shorten the path length and yes I always wondered why it used hashes that long.