Kodi, inputstream.adaptive and Netflix not working...

In a previous post, I mentioned how I finally solved an issue with the Netflix add-on for Kodi and how items didn't play properly but sound worked fine. It was due to the Raspberry Pi not being powerful enough since it has to do software decoding.

However, I did an update from 9.0.1 version of Libreelec to 9.0.2 and for some reason, Netflix wouldn't even play the video.

Looking through the logs I could see that the /usr/lib/kodi/addons/inputstream.adaptive/ directory couldn't be found which lead to a lot of Googling and no answers. I tried uninstalling, re-installing inputstream.adaptive and tweaking with its settings, even changing LD_LIBRARY_PATH to point to a different location... all in vain.

How did I solve it? I uninstalled the Netflix addon, and reinstalled it.

I removed all settings prior to the removal, but you might not need to do that. I just didn't want to have to deal with it not working and thought it might be a good idea.

So, there you go. Neflix not working on Libreelec (doesn't matter which version) on a Raspberry Pi. Uninstall the addon and add it back in! Why? Not sure... but at least it's working now.

Kodi, inputstream.adaptive and Netflix

One of the things I love about the latest version of Kodi is being able to use the Netflix add-on and being able to view everything in one place.

I had a problem that took me a bit to troubleshoot. Whenever I watch Netflix, I noticed that videos would start to play slower than the audio. In other words, the video would look like it was in slow motion while the audio played at normal speed.

After doing updates, downgrades, etc I finally found that people were discussing this issue but weren't able to reproduce, however, while looking at the issue myself, I noticed the videos that I was watching from Netflix were in 1080p quality. I went into the properties for inputstream.adaptive and changed the settings to the secured streams from MAX to 720p.

It worked! My Netflix streams are smooth like butter.

Happy New Year!

2018 has come and gone! It went by so quickly!

I hope that the new year will be great, and bring you success.

That 2019 brings some sanity back to the world!!!

Beyond that, that you can spend it with your family and friends. That all your goals for the year are a success.

I wish you all a Happy 2019.

Happy New Year!

Pidgin Part 3 - Or how I learned to ha... dislike Lync

The company is migrating to MS Teams in the near future. This is actually great and seems to work with Linux quite well, even if there isn't an official client for Linux. If Microsoft were to actually make a full Teams client for Linux, that would be the first official application I'd be running on my Linux laptop.

That said, we haven't actually fully moved to Teams, and are actually still using Lync (while moving to Skype-for-Business i.e. Lync 2016) in the nearer future. I'm still on the old Lync server and now, for some reason, my Pidgin-Sipe client has stopped working.

I cannot seem to connect to the server and I haven't found out why yet.

Currently, when running Pidgin with the --debug flag I get the following.

(14:03:26) sipe: sipe_http_request_response_unauthorized: init context target 'HTTP/server.domain.com' token '<NULL>'
(14:03:26) sipe: sipe_http_request_response_unauthorized: authentication failed, throwing away context

Obviously, I'm not giving out the server name.

It's a different error than having an incorrect password, so I'm not sure what the problem is. (Yet.)

If anyone happens on this blog and has more input or an idea, please add it in the comments.

Getting Pidgin and Microsoft Lync to work nicely (Part 2)

I last wrote about trying to get Pidgin working on a Windows environment by using the pidgin-sipe plugin and a few other things. (See the first post.)

Since then, I've changed work/company and decided I would go with TelRed's Wync Sky and even pay for the year's subscription. However, even with the license I still had a lot of issues. Also, since the group that I work with worked on Skype instead of Lync, I was using Skype for Linux and didn't bother trying to sort out my issues.

However, people need me to be available via Lync now. I decided to give Pidgin another go.

So, following what I knew from the first post, I edited the UserAgent and put in the rest of my information.

Well, it wouldn't work. The error I got was something related to the service not providing a token. I couldn't find any Pidgin logs, so I started it on the command line with the -d flag (for debugging.) and I noticed that it wouldn't accept the SSL certificate and would disconnect me.

Reading about this issue, it led me to enable the NSS Preferences plugin and then trying to figure out what Cypher the site I was trying to connect to was using. The logs didn't give much information with regards to that, so I tried Google Chrome. I couldn't find the information in Chrome by viewing the SSL Certificate itself, but going to into Developer Tools, and then the security at the bottom it showed that the site was using some old Cyphers and protocols. I enabled those in the NSS Preferences plugin and then my error changed!

Now, it was still failing, but it gave me a "Read" error. I googled for that and eventually came to an OLD Debian bug (649456) which showed that the workaround was to use NSS_SSL_CBC_RANDOM_IV=0 and then start pidgin. So, I did that and voila!

I'm available on Lync now. I now noticed I can even do some other things that I couldn't before, but I haven't had the chance to try them.

Last thing: we are migrating to O365 soon, so I will probably have to write another part to this saga when that's completed. I believe there's going to be two steps to that since we're doing email first and moving the Lync instances to Skype 4 Business second.

Keep your eyes out for the next instalment.

Happy New Year!

2017 - another year added to our belt.

I hope that the new year will be bring you joy.

That 2018 will be a successful year.

That you can spend it with your family and friends because you'll never know how much you'll miss them until you cannot spend time with them.

I wish you all a Happy 2018.

Happy New Year!

Backups? Who needs stinking backups!

It's not often that I get to write about a success followed by a failure... followed by a success.

I run Linux on my corporate machine (Ubuntu in one flavour or another) and I had not upgraded in a while. This meant that my version of Ubuntu was End of Life and I need to completely re-image my laptop to get onto something more current.

Therefore, I did what anyone would do... backup my data.

I then attempted a restore to make sure that the data was still valid and "restorable" and proceeded to re-image my machine.

I hate to name and shame, but I used Deja-dup which is the default Ubuntu backup software to create my backups and check that everything was working.

However, after re-imaging my machine and installing the latest version of Ubuntu, I tried to restore my backup and lo-and-behold, Deja-dup tells me "There is no backup...."

WHAT?!

Are you might assume, I went ahead and tried to find what I could do - I saw that all the backup files (duplicity-full.xxxx.tardiff.gz) were in the backup location so I didn't think anything about it...

I tried re-launching the application and when I did it tried to make a backup. I didn't want a backup, so I stopped it. Then started the app again and tried to restore with the same error message.

I decided I would try something else, so I go to the directory where my backup was located and.... it was empty! Actually, there was a duplicity-checksum file that had been created by the previous backup attempt.)

WHAT?!

I couldn't believe my eyes. I wanted to die! I had not only documents but also code I had written. I had over a year's worth of work, notes, and items that I had saved... ALL GONE!

ALL! GONE!

So, I started looking for what I could do to recover something that was recently deleted. I found ext4magic and extundelete...

I installed both, made my partition read-only (which was an encrypted drive.)

sudo mount -o remount,ro /dev/mapper/luks-<uid-of-drive>

I then proceeded to read the documentation on both and decided that extundelete was worth a shot...

I created a temporary directory to try to restore into and ran the application (and crossed my fingers) ...

sudo extundelete /dev/mapper/luks-<uid-of-drive> -o RESTORE/ --restore-all

I waited. And finally...

42GB recovered!

I then copied them over to another drive (for safe keeping) and tried to restore from those files... Still, Deja-dup said, "No backup found!" $!*&"!

I went and looked for what I could do to recover if I didn't have Deja-dup and I found that I could simply gunzip and untar the files. That it would create a "snapshot" directory and a "multivol-snapshot" directory. Everything in the "snapshot" directory was the file in the original state... while the other one contained parts which had to be put together.

Well, I did it... and I've recovered almost all the stuff I had.

Now to switch to something that I have used before and that works quite well... Back-in-time.