[confirm] Bring back "restart un resume" functionality (1 Viewer)

[megahorst]

And leaving the option in/reinstating this option stops you solving these issues, how?
Is there a specific technical reason why it is particularly onerous and/or problematic to bring this option back?

This option was added to work around a specific issue that I wasn't even aware of, but has been used by many other users, quite successfully, to solve other problems - the source of those problems is really quite academic, if they have no means to solve it because it relates to interaction with a third party plugin. You now have a body of people that are employing even hackier external workarounds to solve their issues - in my case the latest hack doesn't even work.

Rather than just someone saying "no" - what is the constructive process to suggest that this returns as an option within Mediaportal so that end users get a chance to vote on it?

I can understand the mediaportal team. They are focussing on getting rid of issues. Introducing workarounds leads to not finding the reasons for your problem.

From my point of view you have at least tree options:

1. Mediaportal is freeware you can build your own version with this option inbuild
2. Ask google for a tool that is restarting certain processes after resuming
3. Start MePo with the "Watchdog tool" and send the zip that is created automatically with the logs inside. In this post you should descibe in detail what the problem is.

 

[mm1352000]

Before I answer your post...
I can see that you're passionate about this topic, and I'm glad. I think it is great when people are passionate about MP.
I'm also passionate about MP, and I'm here to help not to try and frustrate you.

And leaving the option in/reinstating this option stops you solving these issues, how?

It hid issues. Nobody bothered to investigate real causes or even report issues.

Is there a specific technical reason why it is particularly onerous and/or problematic to bring this option back?

It is probably not particularly onerous to bring the option back. However, the decision to remove the option had nothing to do with the technical complexity of the function. It was a design/strategic decision.

This option was added to work around a specific issue that I wasn't even aware of, but has been used by many other users, quite successfully, to solve other problems

While I agree that many people may have been using the option, I don't agree that it was an adequate solution because it didn't actually address the causes of the problems.

...the source of those problems is really quite academic...

Again, I don't agree. If you know the source of the problem you have a chance to fix it. From a team perspective that is a much better situation than we had before. From a user perspective you may not care about the source of the problems, but from a team perspective we care. We want a quality product with quality plugins.

...if they have no means to solve it because it relates to interaction with a third party plugin.

We don't want a product where users have to enable such options to make the product behave optimally. Rather, we want a product that "just works". The user does have means to solve the problem: bring the problem to the attention of the developers and work with them to locate and resolve the issues.

You now have a body of people that are employing even hackier external workarounds to solve their issues...

While that may be partially true, it is certainly not entirely true and I think a little unfair. Look at the work Sebastiii is doing with the TV Server detection. That would never have happened previously.

...in my case the latest hack doesn't even work.

The "latest hack" as you call it was not intended as an alternative.

Rather than just someone saying "no" - what is the constructive process to suggest that this returns as an option within Mediaportal so that end users get a chance to vote on it?

I think the question is "skewed", but I'll try to answer it anyway. From my perspective the only justification for adding the option again would be if we identified a problem that we could not solve in any other way.

If you want to be constructive I'd encourage you to post log files and system information - co-operate with us to find and fix the underlying causes of the problems for you (and for other people). If you're not willing to do that then we are severely restricted in how we can help you. If you do that you would also have more credibility and "ammunition" to convince us that we need to add the option again in the case that we fail to identify or solve the problem for you.

 

[c128]

If you want to be constructive I'd encourage you to post log files and system information - co-operate with us to find and fix the underlying causes of the problems for you (and for other people). If you're not willing to do that then we are severely restricted in how we can help you. If you do that you would also have more credibility and "ammunition" to convince us that we need to add the option again in the case that we fail to identify or solve the problem for you.

I'm in no way unwilling to post logs here, I have done many times before in the years I've been a member here, but in this case the logs won't help - at least not in a Mediaportal-centric context - the issue no doubt lies with Argus TV integration and I have a separate issue open on the forum over there:

http://www.argus-tv.com/forum/viewtopic.php?f=59&t=4158

Yes, this actual fix lies there but, no, it's unlikely to be quick coming (or at all, even).

I could totally appreciate your argument were the people that lament the loss of this functionality arguing for (a) active functionality to be developed from scratch to serve as a workaround for a third party issue or (b) for functionality that could not be disabled that hid issues by default - that would be unreasonable. The thing is, this isn't true in this specific case - the functionality pre-existed, people were making use of it for a variety of reasons and it was switched "off" by default anyway - it provided an option for people that were having a variety of issues, not just within Mediaportal itself. Blanket removal of it has caused problems for many, and I suspect not for the reasons you were expecting?

I'd suggest that removing generic options (and it had become a generic option - I wasn't even aware of why it was originally introduced) like this could be done in a far less heavy-handed way in the future and so impact users far less, IMHO. Removal of the option from the UI and relegating it to the standalone Mediaportal configuration would have been one option, only allowing it to be enabled via config file etc. change would have been another. That way you could have warned about any future removal and effectively deprecated the functionality over time, leading to external fixes being available in readiness. As it stands though, it's gone - short of getting a quick fix from Argus, which seems unlikely as not everyone experiences it, I'm left with downgrading to a prior Mediaportal version to return to real stability - this seems largely unnecessary to me, for the reasons above :-( .[DOUBLEPOST=1374944473][/DOUBLEPOST]

I can understand the mediaportal team. They are focussing on getting rid of issues. Introducing workarounds leads to not finding the reasons for your problem.

This was the removal of functionality - no-one's asking for a workaround to be introduced, just for a generic option that restarted Mediaportal on resume to be available again, as they were depending on it for reasons that I believe were not considered when the design decision was made to remove it. The fix in my case doesn't even lie with Mediaportal itself, hence it's not disguising any issue in the core product.

From my point of view you have at least tree options:

1. Mediaportal is freeware you can build your own version with this option inbuild
2. Ask google for a tool that is restarting certain processes after resuming
3. Start MePo with the "Watchdog tool" and send the zip that is created automatically with the logs inside. In this post you should descibe in detail what the problem is.

Well, yeah, I guess I have many options, none of which are preferable to the option existing within Mediaportal as it had done for some time .
I could use XBMC, but we all know that that's pretty crap compared to Mediaportal (at least for PVR use).

I don't think this is really the point though.

I understand the rationale for removing the option, even if I don't agree with it, but I think the reasoning didn't take into account the variety of reasons folk might have been using it - typically changes like this are done through warning and deprecation before removal, giving time for changes to be made to take account of its impending absence.

 

[mm1352000]

...but in this case the logs won't help - at least not in a Mediaportal-centric context - the issue no doubt lies with Argus TV integration and I have a separate issue open on the forum over there:



http://www.argus-tv.com/forum/viewtopic.php?f=59&t=4158

Right, I see - thanks.

Yes, this actual fix lies there but, no, it's unlikely to be quick coming (or at all, even).

I had a quick look at the Argus client code but unfortunately the source of the exception I see in your log files is in a closed-source DLL. Maybe the cause is in the open source code, but there is too much code in the plugin for me to understand and start troubleshooting in a short space of time.

Having said that, I'm wondering if this could be a general network issue... because surely more people should have reported it if it were a general Argus integration issue. Don't get me wrong. I know very little about Argus - just trying to assist.

Can you confirm:

• are you running the Argus server or the MP server?
• do you have a single-seat or multi-seat system?
• if multi-seat, is the problem occurring on a client-only PC?
• does your TV Server have a static IP address?
• is your TV client and DB connection configuration using hostname or IP address?

Blanket removal of it has caused problems for many, and I suspect not for the reasons you were expecting?

Yes, there have been some unexpected things that have "come out of the woodwork". However, I think that was always going to be the case.

I'd suggest...

Fair enough - I take your point.
Having said that, we're not usually so well planned as you might think. Deprecation of options or interfaces... I don't recall any cases where we've done that in the past. We're trying to do better, one example being the Windows XP support. Yeah, I can only say I understand your perspective too.
I note that the main feature branch for MP 1.4 was available for testing in A51 for months:
https://forum.team-mediaportal.com/threads/call-for-tester-for-1-4-0-features-and-fixes.114566/

Yes I admit it was probably not clear that the option was being removed there. However, the original reason for the option being present was related to a D3D/GPU issue. So, when the option was removed it was done with the D3D rework and lots of testing...

 

[c128]

Thanks - I appreciate the general background to this and the detail.

Having said that, I'm wondering if this could be a general network issue... because surely more people should have reported it if it were a general Argus integration issue. Don't get me wrong. I know very little about Argus - just trying to assist.

Can you confirm:

• are you running the Argus server or the MP server?
• do you have a single-seat or multi-seat system?
• if multi-seat, is the problem occurring on a client-only PC?
• does your TV Server have a static IP address?
• is your TV client and DB connection configuration using hostname or IP address?

I guess it could be something subtle in the network setup... I'm not really sure how many folk are experiencing that use Argus as I'm not totally sure how many people use Argus and have both their client and server S3 sleep and wake for use. Everything did work fine once - the issue came up with the Mediaportal 1.3.0 beta and Argus 2.0.1, but that could just have been a coincidence.

My network is all wired and is pretty robust in general but, yeah, that's a point.

• are you running the Argus server or the MP server?

Argus server

• do you have a single-seat or multi-seat system?

Multi-seat, but only one Mediaportal client (and one XBMC client - no issue there, other than XBMC just not being as good as Mediaportal )

• if multi-seat, is the problem occurring on a client-only PC?

Only one Mediaportal client - client-only.

• does your TV Server have a static IP address?

It does

• is your TV client and DB connection configuration using hostname or IP address?

Hostname - that's a good point. I could try IP address - I seem to remember there being an issue with resolution causing delays in the dim and distant past, so there could be a knock on impact. Something for me to try there that I'd totally forgotten about.

Thanks for the comments - I'll try and push a bit more on the Argus forum - difficult as the community is a bit smaller there and a lot of the activity these days seems more XBMC related.

 

[mhoogenbosch]

My problems with resuming from S3 keep on going. I'm loosing the WAF, can't explain why she always have to close MePo before using it.

I have created a seperate thread, https://forum.team-mediaportal.com/...ith-small-screen-comming-from-standby.120189/ but the replies have run dry. I've posted my logs. Basicly i have one problem, with three possible scenario's.

1. System resumes and MePo is at the upper left corner in a 1024x768 resolution within my 1080p screen. Closing MePo and starting it up again resolves it.
2. System resumes, MePo is full screen but has messedup fonts. Everything is extremely big and almost can't be read. Closing MePo and restarting it, resolves the problem.
3. It just works.

The bad thing is that around 5% of the wakes it is scenario 3. As i said, my logs are in the other thread but could send new ones if it is needed.

I am using ARGUS aswell, but i don't think my problems are related to that.

 

[Requiem]

+1.

1. When resuming from S3, I'll also occasionally have a wrong MediaPortal resolution. Restart on resume used to solve this.2. On other occasions, MePo will not run in foreground when resuming from S3 so I'll have to fetch the keyboard.
3. On other occasions, I'll get a "MePo has stopped working" on resume.
4. Sometimes, everything just works.
Not using Argus.

I understand the developer's view, wanting to track down and resolve bugs, and I'll happily provide you with logs as I did before, but the situation now is quite frustrating, as I went from a stable, running system on 1.3 (even if this was only possible with a workaround) to a system which is easier to reboot than to wake from standby (regarding functionality).
Some issues seem not to reside within MediaPortal, as the screen resoultion (I think this might be a HDMI handshake timing issue) and are - if I am right - not fixable by the MePo Team.

If the development team does not want to bring the feature back to the main program, what about an external addon? If I could do such stuff myself, I would...but unfortunately I can not. But wouldn't this be a good idea to bring together the needs of developers and users as well?

 

[markus_g]

+1.

1. When resuming from S3, I'll also occasionally have a wrong MediaPortal resolution. Restart on resume used to solve this.2. On other occasions, MePo will not run in foreground when resuming from S3 so I'll have to fetch the keyboard.
3. On other occasions, I'll get a "MePo has stopped working" on resume.
4. Sometimes, everything just works.
Not using Argus.

I understand the developer's view, wanting to track down and resolve bugs, and I'll happily provide you with logs as I did before, but the situation now is quite frustrating, as I went from a stable, running system on 1.3 (even if this was only possible with a workaround) to a system which is easier to reboot than to wake from standby (regarding functionality).
Some issues seem not to reside within MediaPortal, as the screen resoultion (I think this might be a HDMI handshake timing issue) and are - if I am right - not fixable by the MePo Team.

If the development team does not want to bring the feature back to the main program, what about an external addon? If I could do such stuff myself, I would...but unfortunately I can not. But wouldn't this be a good idea to bring together the needs of developers and users as well?

Hi I noticed you have a Sony Bravia. I had a similar issue when going to MP 1.4. What I had was a VGA and a HDMI cable plugged in to the Bravia. Even though I only use the HDMI, unplugging the VGA fixed my situation.

 

[Requiem]

Thank you.indeed,I use a vga connection for some purposes, I'll try that. However, VGA
output is disabled upon Windows startup.
But this is exactly what i described above...
Unforeseen conditions beyond MPs reach.not all of them are quickly solvable, and not by the development team. So, several people will need a workaround, no matter how many bugs are fixed in mp
itself.

Any comments by the developers about the idea of making this option a separate plugin? Maybe with some other options that didn't make it in the main product? Or at least enable it with the config debug options like timeshift UNC paths?

 

[mhoogenbosch]

Okay, I've not replied for a while now but that was due some testing. I believe it is fixed with my setup.

I've changed the input on my receiver. Didn't know this could impact this, but apperently it does. I first had the HTPC connected to the PC input on my Onkyo receiver. I've changed that to CBL/SAT instead, and now it is always full screen.

I have even changed back the input to 'PC', the problems reoccurred.

Weird, but problem solved.