Scythe42's fixes for 1.4.0 | Page 26

Discussion in 'Area 51 - Testing Area' started by elliottmc, April 19, 2013.

Thread Status:
Not open for further replies.
  1. Wo0zy
    • Premium Supporter

    Wo0zy Retired Team Member

    Joined:
    April 30, 2008
    Messages:
    394
    Likes Received:
    128
    Gender:
    Male
    Ratings:
    +148 / 0
    Home Country:
    United Kingdom United Kingdom
    Hi Scythe,



    Yes. I have the problem as well. Only just realised. But I'm not currently running your latest build so will update, re-test and if the problem is still present I'll post logs.

    Cheers,

    Wo0zy
     
    • Like Like x 3
  2. Google AdSense Guest Advertisement



    to hide all adverts.
  3. edterbak
    • Team MediaPortal

    edterbak Test Group

    Joined:
    March 4, 2008
    Messages:
    2,114
    Likes Received:
    736
    Gender:
    Male
    Occupation:
    Researcher
    Ratings:
    +1,178 / 5
    Home Country:
    Netherlands Netherlands
    Show System Specs
    Scythe.
    I want to test for you/us this evening. Gatto catch the train. :)
    Could you be clear on what you still need tested? Howto reproduce.. etc.
     
  4. Scythe42
    • Premium Supporter

    Scythe42 Retired Team Member

    Joined:
    June 20, 2009
    Messages:
    2,065
    Likes Received:
    2,632
    Gender:
    Male
    Occupation:
    Professional Hacker
    Location:
    Berlin
    Ratings:
    +2,724 / 1
    Home Country:
    Germany Germany
    Show System Specs
    Regarding the locking: Using foreach with a dictionary in a public context is not thread safe. That is the nature of a Dictionary and how foreach uses it. As soon as a key is added or removed the foreach cannot continue properly. LINQ should show the same.

    That is the only thing in TV-Series that requries for 1.4.0 as a quick and dirty fix. The rest should be fine as no other exceptions or issues were reported.

    But coming to the defense here of TV-Series right away: It is not clear which other thread uses the same object. In theory could even be another plugin as the methods are public.

    But by locking the foreach loop when going through the Dictionary, TV-Series itself will not cause an exception and can continue. And is is just for logging some information. The rest seems to run fine.

    What needs to be done in the long run:
    • Check if any other thread create by TV-Series modified the Dictionary during initialization
    • Make these methods internal instead of public to avoid other plugins recycling them.
    Dictionaries and thread safe programming are always a pain. They require a lot of locks as Dictionaries in C# are not thread safe.

    Starting with .NET 4 MS introduces a thread safe dictionary exactly for that reason: http://msdn.microsoft.com/en-us/library/dd287191.aspx
     
    • Like Like x 1
  5. Scythe42
    • Premium Supporter

    Scythe42 Retired Team Member

    Joined:
    June 20, 2009
    Messages:
    2,065
    Likes Received:
    2,632
    Gender:
    Male
    Occupation:
    Professional Hacker
    Location:
    Berlin
    Ratings:
    +2,724 / 1
    Home Country:
    Germany Germany
    Show System Specs
    Can you please give this MediaPortal.exe a quick try and let me know if this changes stuff?

    If not I need to add some debug logging to the timer methods to see where a wrong or unexpected value is coming from.
     

    Attached Files:

    • ForHomeY.7z
      File size:
      340 KB
      Uploaded:
      April 27, 2013
      Views:
      48
    Last edited: April 27, 2013
  6. HomeY
    • Team MediaPortal

    HomeY Test Group

    Joined:
    February 23, 2008
    Messages:
    6,460
    Likes Received:
    2,627
    Gender:
    Male
    Occupation:
    Network Engineer
    Location:
    ::1
    Ratings:
    +4,737 / 16
    Home Country:
    Netherlands Netherlands
    Show System Specs
    Won't start on HTPC:
    Code (Text):
    1. [2013-04-27 14:06:39,231] [Error  ] [MPMain  ] [ERROR] - D3D: Could not create device
    Hangs on initializing.

    On DEV (your branch):
    Code (Text):
    1. [2013-04-27 14:12:11,504] [Error  ] [MPMain  ] [ERROR] - D3D: Could not create device
    2. [2013-04-27 14:12:19,593] [Log  ] [MPMain  ] [ERROR] - Exception: System.NullReferenceException: Object reference not set to an instance of an object.
    3.   at MediaPortal.D3D.InitializeDevice()
    4.   at MediaPortal.D3D.Init()
    5.   at MediaPortalApp.Main(String[] args)  Message: Object reference not set to an instance of an object.  Site  : Void InitializeDevice()  Source : MediaPortal  Stack Trace:    at MediaPortal.D3D.InitializeDevice()
    6.   at MediaPortal.D3D.Init()
    7.   at MediaPortalApp.Main(String[] args)
    8. [2013-04-27 14:12:19,594] [Error  ] [MPMain  ] [ERROR] - MediaPortal stopped due to an exception Object reference not set to an instance of an object. MediaPortal  at MediaPortal.D3D.InitializeDevice()
    9.   at MediaPortal.D3D.Init()
    10.   at MediaPortalApp.Main(String[] args)
     
    Last edited: April 27, 2013
  7. SilentBob

    SilentBob Portal Pro

    Joined:
    January 1, 2011
    Messages:
    54
    Likes Received:
    38
    Ratings:
    +50 / 0
    Home Country:
    Germany Germany

    in principle you are right and this would be the full and clean solution. That's why i wrote
    because in whole code the dictionary is just added or updated no deletion is done.
    the only thing what could happen is that you read an old value, but the key will be always available.


    Nevertheless see scythe post
    https://forum.team-mediaportal.com/threads/scythe42s-fixes-for-1-4-0.118345/page-26#post-988762
    For this .Net 4 would be needed, but also having these concurrent data types in place, multithreading is a powerful mechanism for which some preconditions have to be established in advance. Also senior developer sometimes feel the pain with it.

    What should be fixed here is also just one thing of a long way getting all plugins thread-safe. There needs to be more guidance for plugin developer as well: what is allowed what not. Providing public APIs should always be thread-safe.
    Especially the initialization is a critical phase, if a plugin1 is in initialization phase and not yet ready to be used, another plugin2 cannot use the public APIs, because plugin1 did not reach the "ready" state.

    Threading issues are mostly timing issues, hard to reproduce and for an understanding you need to have the big picture (what is running in parallel, what are critical sections, which unexpected execution order can cause a problem)

    That's why I also said in my last post, maybe it would be an idea to think about a controlled parallelization.
    1. create a dependency graph of all available plugins
    2. find the plugins which do just depend on native MediaPotal and not on other Plugins, they can all be initialized in parallel
    3. find the plugins which depend on MediaPortal and the plugins initialized in previous step they can all be initialized in parallel
    4. repeat 3rd step until all plugins are initialized
     
  8. seco
    • Team MediaPortal

    seco Development Group

    Joined:
    August 7, 2007
    Messages:
    1,579
    Likes Received:
    897
    Gender:
    Male
    Ratings:
    +1,234 / 4
    Home Country:
    Finland Finland
    Show System Specs
    Yes, in general multithreading is a tough subject. I think we haven't seen all the problems yet and we should do more testing, that's why I feel we should not include threaded plugin loading in MP version 1.4.0. This also was already discussed internally and probably the way it's going to be.
     
  9. FreakyJ
    • Team MediaPortal

    FreakyJ Development Group

    Joined:
    July 25, 2010
    Messages:
    4,021
    Likes Received:
    839
    Gender:
    Male
    Ratings:
    +1,424 / 1
    Home Country:
    Germany Germany
    this is done in MP2 :)
     
  10. legnod
    • Premium Supporter

    legnod MP Donator

    Joined:
    September 24, 2011
    Messages:
    1,115
    Likes Received:
    275
    Gender:
    Male
    Location:
    Stuttgart
    Ratings:
    +303 / 0
    Home Country:
    Germany Germany
    Show System Specs
    Closing MP does not work at all (doesnt depend if fullscreen/window) if "reduce MP to tray on exit" is enabled and action "97" is called from within the GUI to close MP. (this is used by topbar and some other menus within the GUI)

    Please dont get me wrong...i dont use this setting at all but this thread is for testing so i test everything available :)
    I am totally on your side that MP has a lot of settings and features that maybe nobody really uses and makes it hard for the developers.
     
  11. Wo0zy
    • Premium Supporter

    Wo0zy Retired Team Member

    Joined:
    April 30, 2008
    Messages:
    394
    Likes Received:
    128
    Gender:
    Male
    Ratings:
    +148 / 0
    Home Country:
    United Kingdom United Kingdom
    :( Hi @Scythe42,

    Updated to latest build from 1st post (sorry it took so long), launched MP in debug mode to capture logs and the problem was still there (GUI rendering @32fps). Accidentally shutdown the system on MP exit (instead of close) and on restart there were no logs on my desktop :( . However, after launching MP again, the problem has now gone (MP rendering GUI @ 50fps)???

    Happy with the result but wondering why :confused: .

    Will do some more testing tonight and will let you know if I find anything. In the meantime if there's anything you want me to check just let me know.

    Sorry I haven't been able to provide any useful data. Only thing I can think to add is that prior to installing this build I was using the first "internal" 1.4 build which included your branch. Quite a lot has changed since then. Having said that, it doesn't explain why @HomeY still sees this problem. There must be something we're missing?

    Cheers,

    Wo0zy

    Edit. And all of a sudden the issue returns..... :eek: . Debug logs attached. Hope they help.
     
    Last edited: April 27, 2013
Loading...
Thread Status:
Not open for further replies.

Users Viewing Thread (Users: 0, Guests: 0)

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice
  • About The Project

    The vision of the MediaPortal project is to create a free open source media centre application, which supports all advanced media centre functions, and is accessible to all Windows users.

    In reaching this goal we are working every day to make sure our software is one of the best.

             

  • Support MediaPortal!

    The team works very hard to make sure the community is running the best HTPC-software. We give away MediaPortal for free but hosting and software is not for us.

    Care to support our work with a few bucks? We'd really appreciate it!