Pi Config not saving settings

Hi guys,

I was just now flashing OSMC for a friend of mine and went to PiConfig to tinker with the settings, when I noticed that the settings I was applying aren’t saved. Neither one by one, nor as many settings grouped together. I was able to verify this on my own up to date OSMC installation. Both of them are dist-upgraded as of right now. This is on a RPI2 on different SD card brands. The usual “restart if you change settings” message if missing as well.

Is anybody able to confirm? I’m happy to upload debug logs if wanted/needed!

Ralph

Nothing can be confirmed without logs…

C’mon man, this is a matter of hitting PI Config and attempt to change a setting and save.

Anyway, here they are… http://paste.osmc.io/upagucikis

Thanks

You are literally the only person reporting the issue…

Why do you assume that the problem you’re having affects every single OSMC user and that reproducing it is as simple as anyone else trying to use the Pi Config module ?

You don’t think if the Pi config module was totally broken that there wouldn’t be a lot more reports of trouble, and that logs would be necessary to figure out why it is happening to you in particular ?

You even said you were happy to upload debug logs if they were needed so…

Edit: your Kodi log shows a crash report for My OSMC that we can use, so the problem is being investigated.

I am having the same issue. I switched to a new pi2 and tried to change the mpg2 license but it never tells me I need to reboot and never saves the new key.

However, if I manually edit the config.txt it saves the changes just fine.

Would not surprise me that most OSMC users edit the config.txt manually without using the PiConfig program…

No idea, but I used it once in RaspBMC and there is worked perfectly, but through SSH is so much easier (copy/paste).

I feel like I have to get something off my chest regarding not only, but in particular the attitude
at the beginning of this thread. I’m aware it has nothing to contribute to the solution and if it’ s considered to cross certain boundaries, feel free to delete it or ban me entirely.

Let me explain.

There is the [quote=“ActionA, post:2, topic:11817, full:true”]
Nothing can be confirmed without logs…
[/quote] statement to begin with. A bold statement on it’s own, but regarding the problem I described, this is just plain wrong. In my following post, not only did I provide the debug logs, I also tried to explain why the symptoms of this specific problem can be reproduced quite easily, and certainly without the need of the logs.

Even if I’m the only one reporting this, doesn’t necessarily mean, that is a non-issue. I understand
that it comes with some unlikeliness and I’m sure the devs have seen their fair share of that, but again
I didn’t post this without verifying this on two PI2s with two different SD cards hooked to two different
power sources using a greenfield installation AND a updated installation. Occurred every single time, which made me think it’s worth sharing.

Then…

Let me explain my train of thought on the above!

The original December update featured a new and improved sdcard driver which, after further review was reverted back to the original driver for issues that are not relevant in this discussion. Furthermore the December update featured a broken PiConfig package which was corrected shortly thereafter. All of this led me to think, that MAYBE the PiConfig module may have some more issues, which in turn led me to ask if anybody else has this…

Well not necessarily because:

  • You don’t hit Pi config that often coming from an upgrade to another because, well, your system is tweaked
  • New users tend not to use this because they are unsure or don’t want to risk to screw their installation
  • User relying on automated configuration like Ansible (in my case) won’t notice this possible bug because ssh-ing in your system and changing the config.txt works as expected

Those were just a few from the top of my head…

Now!

Would it have killed me to provide the debug logs straightaway? Certainly not. Will I provide them in the future. Absolutely! Is this lecture-ish tone really necessary? I want to think it is not.

But guys. I understand you’re doing this in your free time and are sick and tired of chasing debug logs. I get that. I really do. Furthermore I’m immensely grateful for the work you are doing. I mean that. But we’re all part of this community which I really like and therefore sometimes a slightly more friendly tone would sure help.

Just my 2c… I don’t mean to attack anybody with this, it’s just something that I noticed.

I can’t stress it enough, your work is highly appreciated and respected.

Have a nice evening.
Cheers
Ralph

And all of these keystrokes would have been unnecessary and the relevant team members would have been able to immediately see an issue by simply providing logs (as you were happy to do, thx) from the very beginning, just as we recommend and request in the “How to create a useful support request” FAQ. I’m sure you’ve seen our form letter styled link that we must inevitably post on quite a high number of threads. Logs is the way to debug issues. Any number of variables could be at play in any given issue and the most direct way for support personnel to quickly get the most accurate info is by requesting such logs. Sorry if my request didn’t include enough smiley emoticons :wink:

Look man, I agree, it was my bad and that is out of the question. I think I made that clear. You don’t need to use emoticons or smilies etc. In fact, you don’t need to do anything at all. I tried to be helpful here and my mistake was that I wasn’t as helpful as I could have been. If what I’ve written above doesn’t make any sense, then ignore it, that’s fine by me.

I only presented you with my opinion on which you can reflect or not. No hard feelings.

Cheers

Found the issue, it will be fixed in the next update.

To get the fix now go to MyOSMC, Updates, Manual Controls, Apply HotFix and enter this code: [deprecated]

After that, reboot, and the problem should be solved.

Give it a try and post the logs if it fails.

Thanks a lot. Works for me!

Ralph

Great to hear. Sorry about the inconvenience.

Can you mark this post as solved and link to my post?

No worries @Karnage . Thanks for the timely fix!

Say, I noticed that the December images are missing. Any word if this iteration will be skipped, or is it just taking longer this time?

THX
Ralph

I don’t think you genuinely believe that based on your first post, and that’s OK.

The attitude here isn’t right. You present a dissenting opinion and then infer that if one doesn’t agree, you should be banned (and further gain some form of victimhood).

This is a common pattern. One user experiences an issue, and assumes it must be widespread and wants it fixed at the highest priority.

You’ve been on this forum for a while and you should know what’s needed to confirm a bug exists. If something’s really broken, then it should be easy for you to produce a log to confirm this. We’ve made the log uploading process as simple as possible: you can now do it from your remote. We’ve also highlighted what logs we need in a sticky thread, and we’ve tried to make it as evident as possible that logs are needed to identify a problem. Even if we didn’t see a log today, but had heard of the problem, we wouldn’t have been able to fix the issue without one.

We’re helping many, many users in our own free time. We see posts regularly, where either the issue is isolated or not commonly reported. Not every issue, despite having the same symptoms, has the same cause, and not every issue is indeed an issue (searching power supply will certainly reaffirm this). Asking for logs is important. OSMC is based on Debian. You can customise it in thousands of ways, good and bad. This introduces many variables. If a user is so convinced that an issue is introduced by OSMC, then it should not be too problematic for them to upload a log to support this.

Unfotunately, I won’t be on the forum for some time now. I spend several hours a day on this forum, doing my utmost to ensure any issues we do have are addressed and that users get the support they need. However this is taking too much of my time, and doesn’t seem to be warranted as useful to users. I take each post on a case by case basis. We see many users with the same problems, such as PSU issues. But that’s OK, because they’re new, and each individual should be treated as exactly that, an individuals. But unfortunately time doesn’t permit this.

Replying to your post about these concerns means less time is spent on development. I’d rather spend time working on OSMC, than debating with a user if we’re handling support requests correctly.

Sam

Thanks for your reply @sam_nazarko. I very much appreciate you taking time and I apologize for being a distraction from the more important things.

I feel like we’re going in circles here so I like to conclude this discussion. Almost everything that you wrote in your reply, we can agree on. In fact your posts bottom line, as far as I understand it, is:

  1. You need debug logs at all times to sort things out
  2. You’re sacrificing your free time for this project
  3. Moderating off-topic things like this is tedious and should be reduced
  4. We’re all human

Your bottom line is basically what I was saying in one of my previous posts. I made that clear that not providing debug logs in the first place was a mistake on my side. I should’ve known better. I suspected that all of you are sacrificing your free time for OSMC and I expressed my gratitude for that. I can even understand the tense undertone, if seasoned users like me don’t follow rules.

With the hardware I have at my disposal, I tried to apply some methodology that made sense when conducting the tests and came to the conclusion that this might me an issue. I even elaborated as to whether I think this issue might have gone unnoticed. I did not ask for a bump in priority, nor did I ask for some kind of special treatment. I just wanted to find out if more users are suffering from this. Despite the fact that only one or two user joined in, it eventually turned out that this was an issue which was then fixed in record time. Again, Thank You.

Basically, apart from the issue at hand, all I was saying was, maybe the tone could have been less tense and a good chunk of the replies were along the lines of “you should’ve known better, you should’ve provided debug logs in the first place”.

To wrap things up, what I’m taking away from this is that the undertone in the first couple of posts was justifiable in your opinion and secondly that I will provide you guys debug logs when posting potential issues.

Ralph

This undertone you speak of is purely subjective! Yet you insist in applying your percieved inflection to my initial posts! Please, just move on and for all further correspondence, imagine me dressed in full Ronald McDonald clown regalia as you read my posts.

:smiley:

Got it. I guess this is a good closing line then.

Cheers