[fixed] [4378] Issues accessing network share using the service (1 Viewer)

[Lehmden]

Hi.
Sorry, but I have to correct my statement from Post 25. With the new dll I can choose Network Shares. That's an improvement. But the shares won't be imported correctly. Only the folder structure is imported, not a single video file. It's a step in right direction but not reached the target yet. I don't get any errors when I change to Server as console any more. Right atm I'm reimporting the share with Server as console running. When this is finished (will take a while as I'm using SQLCE atm, just to be sure) I will test if I then can playback the videos if server is running as service also.

 

[Lehmden]

Hi.
Now the Reimport is finished. I can access and playback the videos without any issue, also the server is running as service again. So the only remaining problem is the import itself.

I can add and remove shares and I can use them if I import the shares with server as console. Only thing that did not work is importing media files while server is running at service.

 

[morpheus_xx]

Claus, can you check the attached Network provider? Overwrite the one from MP2-Server\Plugins\NetworkNeighborhoodProvider and try a new import.

I also added Impersonate() calls in all public methods/properties that involve resource access, as it might happen from other threads.

 

[Lehmden]

Hi.
Tested it, did not work, sorry. I've added a network share. MP2 starts to import (as before) But Import did not finish. MP2 Server crashed and could not be started again. I've changed back to previous version of dll and server is starting as service but not as console.

Problemsignatur:
Problemereignisname: CLR20r3
Problemsignatur 01: mp2-server.exe
Problemsignatur 02: 2.0.0.0
Problemsignatur 03: 51770d5f
Problemsignatur 04: Mediaportal.TV.Server.TVLibrary.Services
Problemsignatur 05: 1.0.0.0
Problemsignatur 06: 50eaf28c
Problemsignatur 07: 4e9
Problemsignatur 08: ae
Problemsignatur 09: System.NullReferenceException
Betriebsystemversion: 6.1.7601.2.1.0.256.1
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt

MAybe I need to restart whole PC before any further testing.

 

[morpheus_xx]

Please remove SlimTv.Service from MP2-Server plugins. Seems like it causes some port conflicts and then cannot start (and fails with an exception )

@gibman, can you look into exception handling of TvLibrary here?

 

[Lehmden]

Hi.
I've tried it. But this Provider did not work as it should. After removing SlimTV.Service (found it myself right after writing my previous post) I tried to reimport a share with 6 Movies on. After one hour with server as service I gave up, nothing was imported also in config it looks like the import process is still running. Then I tried to add those 6 movies while running server as console. The Import lasts until eternity, after 2 hours server had 4 out of 6 Movies imported. I did not want to wait another hour to get last two movies imported. Next is to revert changes to see if the import is working like before or the DB is damaged somehow.

After that I will try the SQLite DB...

 

[Lehmden]

Hi.
I'm now using MJGraf's Provider again. The Import of the 6 Movies last about two or three minutes then... But I had to delete the share and add it again to get it imported properly (Server as console running, ofc). So no damage is done to the DB.

 

[MJGraf]

Hmmm,
somehow we should solve this for the next Alpha, because otherwise, the NetworkNeighborhoodResourceProvider doesn't really make sense, when we have MP2-Server running as Service as a Standard.....

From what I read here:
http://msdn.microsoft.com/en-us/library/b80a7e92.aspx
the impersonation of the user works until WindowsImpersonationContext.Undo() is called.
From the example here:
http://msdn.microsoft.com/de-de/library/system.security.principal.windowsimpersonationcontext.aspx
it seems that Undo() is called automatically if the WindowsImpersonationContext is disposed.

Maybe we should impersonate in the constructor and then just Keep the WindowsImpersonationContext in that NetworkNeighborhoodResourceAccessor as a property and call Undo() ourselves in the Dispose-Method of the NetworkNeighborhoodResourceAccessor.
Maybe we should even do that on the NetworkNeighborhoodResourceProvider (I think we always have one Provider but many accessors but not sure about that). I don't really know why your Import takes SOO Long, but I could imagine that Impersonation is (from a computer's perspective) a really Long-Lasting call. What I suspect is that in Morpheus implementation the Impersonation is called a hundret or even thousand times, which then takes really Long...

I'm also not sure, whether this solves the Problem that impersonation is always valid for a given thread and we don't know whether the thread, which instatiates the NetworkNeighborhoodResourceAccessor ist the same that later uses the Accessor. But anyhow it would be worth a try...

Just some thoughts, currently out of home and can't provide a new DLL...

Michael

 

[Lehmden]

Hi

somehow we should solve this for the next Alpha,

Agree 100%
I really like the "server as service" option and I use it as often as possible but every time I need to add media files I have to restart the server in console mode...
If I can help with any testing the next days (excerpt of May, First) I'm glad to do so.

 

[morpheus_xx]

This has to be fixed before we can release a new snapshot. I already added some planned changes to mantis http://mantis.team-mediaportal.com/view.php?id=4378#c6739.

At first I wanted to Impersonate only once in a method, but this didn't work for other methods. I'm not sure if it would be enough to do only in CTOR, as public properties and methods could be called from different threads.

The duration of an "Impersonate" call here is less than a ms, I wonder what takes so long on your systems?