[krustyreturns]

I cheated, just like I said I was going to do . If you delete an episode inside a series directory - and then go up a level - you will see that the episode count for that series is wrong (still has the pre-delete value). After about three minutes it will get the correct value. Its a cheat of course, but I have been using it like this for a while now and for me anyway its good enough. At least good enough until they add this to xbmc proper.

[advocate99]

I suggest that you include the switch for this feature in the GUI so that it can be turned off..

I cheated, just like I said I was going to do . If you delete an episode inside a series directory - and then go up a level - you will see that the episode count for that series is wrong (still has the pre-delete value). After about three minutes it will get the correct value. Its a cheat of course, but I have been using it like this for a while now and for me anyway its good enough. At least good enough until they add this to xbmc proper.

---

Is there a possibility that it will change in ServerWMC **before** the client updates, meaning that in 3 minutes, you won't be able to get into the folder at all because it no longer exists, or does ServerWMC honor both the old one and the new one for a period of time??

I cheated, just like I said I was going to do . If you delete an episode inside a series directory - and then go up a level - you will see that the episode count for that series is wrong (still has the pre-delete value). After about three minutes it will get the correct value. Its a cheat of course, but I have been using it like this for a while now and for me anyway its good enough. At least good enough until they add this to xbmc proper.

[krustyreturns]

Ok, I will put it in the gui on the next release. As you know, it can be turned off in the config.xml right now.

On your second question, it will never contain both the old an new directory names. So yes it is possible that: you are viewing the contents of a folder, then delete a file in there, then just leave the interface alone for around 3 minutes or so, the folder will be blank when it updates. But of course nothing is really lost, if you go up a level you will see the folder is still there.

I did it this way because I really like having the episode count, but my main beef with it was if I decided to delete a few episodes of a series after each deletion I would have to go up a level find the series folder again, go down a level, and delete again. With this change I don't have to do that, it actually seems to work pretty well - at least I think so.

[advocate99]

Understood. But, aren't you concerned about the opposite happening now?

What happens when someone's client hasn't updated, but the server has? They might attempt to go into a folder and find that it no longer exists.

i.e.,

Friends (5)

They delete 1.

The Server updates 3 minutes later and changes to Friends (4), but the client doesn't pull the update right away. The user tries to go into

Friends (5)

But, it doesn't exist. They see nothing! Panic! All of my Friends are GONE!

A bit later, Friends (4) shows up and they are back.

This seems worse than the issue you experienced.

Ok, I will put it in the gui on the next release. As you know, it can be turned off in the config.xml right now.

On your second question, it will never contain both the old an new directory names. So yes it is possible that: you are viewing the contents of a folder, then delete a file in there, then just leave the interface alone for around 3 minutes or so, the folder will be blank when it updates. But of course nothing is really lost, if you go up a level you will see the folder is still there.

I did it this way because I really like having the episode count, but my main beef with it was if I decided to delete a few episodes of a series after each deletion I would have to go up a level find the series folder again, go down a level, and delete again. With this change I don't have to do that, it actually seems to work pretty well - at least I think so.

[krustyreturns]

Weird! I debugged this by copying a bunch of Friends episodes from my main server to my devel computer. I actually never watch the show, so I figured if I made a mistake I wouldn't care.

To answer your question, remember that these directory names are artificial and they are held in the client memory. So if the client hasn't received the update, when the user goes into Friends(5) it will be there. However, if the user lingers in this directory, and then the client receives an update, the files will suddenly be gone since the client now thinks the directory name is Friends(4). But this is really independent of my 'fix', its just the downside of appending episode count to the name.

[advocate99]

Okay, as long as they are held in client memory, I guess it shouldn't matter. Nice work!

[scarecrow420]

yeah just remember all we send back to XBMC is a list of files (with full paths, which are tot he actual physical directory IE that doesnt have any episode count). Each line item also has a "Path" field which is the virtual heirarchy that XBMC client displays as if it were folders. So regardless of what the virtual folder name is, the files the client thinks are inside it, are real links to real physicalfiles. The problem as krusty says is if the client is currently in a virtual directory then receives an update of recording items where none of the recording items haev that virtual directory as their path anymore. So I guess the rule needs to be, if you delete recordings, dont linger! Personally I think this particular feature has ended up not workable with the limitations imposed by XBMC currently and even with the delaying of changing counts when episodes are deleted, I still think the behaviour is ultimately undesirable and would rather see it disabled or removed. But it doesnt really matter either way

[krustyreturns]

This feature is not feeling the love! I will disable it by default in the next rev. Personally though, I like using it, so I'm not going to remove it... no matter how much grief I get

[advocate99]

I like it also, and I definitely would not remove it. I also would not change the default, but I would add it to the GUI, and keep watch to see if it creates any other bugs...

This feature is not feeling the love! I will disable it by default in the next rev. Personally though, I like using it, so I'm not going to remove it... no matter how much grief I get