-current and google-chrome
 

Noticed some issues with google chrome under -current. Having some flash/pepflash lag delays and various problems. Anyone else run into flash related problems in google-chrome under -current?

I've tried varying window manager environments and also with/without flash-player-plugin installed... still get laggy/crashy flash performance.

any ideas?

(64 Bit -current, google chrome 26.0.XX (from 14.0 slackbuild).)

Slack64-Current multilib
google-chrome-25.0.1364.97-x86_64-1.txz <--- used slackbuild from /extra
flash-player-plugin-11.2.202.261-x86_64-2_SBo.tgz
All is well here, no blue people.

edit:
Just built the newest version using the build in /extra and it's also working good.
google-chrome-26.0.1410.63-x86_64-1.txz

I have the same problem in firefox and chrome with kernel 3.8.8 and 3.8.11 as well.
Deleted .kde folder and nothing. can't play youtube videos or similar content

I had to boot again to kernel 3.2.29 and works with no issues.

I'm running Slack64-current

F.Y.I. Chrome does not use the NPAPI Flash plugin provided by flash-player-plugin-11.2.202.261-x86_64-2_SBo but rather the PPAPI (Pepper) Flash plugin it comes bundled with. If you use Chrome as your only browser, you need not even install flash-player-plugin-11.2.202.261-x86_64-2_SBo at all.

Thanks!
I didn't know that. :doh: :study:

@slackass: I don't think that most people realise to be honest. ;)

P.S. If you want an easy way to keep Chrome up to date, you can use my script, latest-chrome. Just make it executable and run it from time to time. If you already have the latest version it will simply print back a message to the terminal telling you this. However, if there is a newer version it will automatically download it and repack it locally into Slackware format (you don't have to run it as root for it to do the repackage as it includes its own makepkg function that will make a package with root owned files even when run as a regular user).

Go to chrome://plugins and disable chrome's built-in ppapi flash to use the SBo or alien flashplayer-plugin only.

Thanks ruario!!

I have been having the same issues. They recently started happening, but not on all websites. Youtube is un-watchable. You can temporarily switch to adobe flash version. Every now and then, pepper flash would do stuff like that. Google is usually pretty fast about fixing those things. I'm sure they will have an update here within the next few days.

:scratch: Looked for that option, but couldn't find it.

On the top right, click on (+)Details.

Thanks. Found it. Now off to the optometrist. :)

Still without the pepperflash plugin you can't view videos at the cbs.com site. As with other browsers and the regular flashplayer plugin, you can view the commercials, but not the show. Once the pepperflash plugin is "re-enabled" you can watch the program. This sort of nonsense by the big corporations really *^%$#* me off! :mad:

OTOH, the KDE developers are pulling the same scam by forcing us to install digiKam if we want to use the kipi-plugins with KDE apps other than digiKam.

Actually disabling peperflash through chrome://plugins did the trick for me. I was looking through the options for that; had completely forgotten that the plugins url feature was even there.

Seems kind of silly though that chrome would ship a built in peperflash that didn't perform properly? In either case I'm use the flash-player-plugin and all seems to work well for me thus far.

Thanks!

I have found out that I get better hardware acceleration performance from pepper flash. However, every now and then, things like this happen. I am pretty sure that it will be fixed soon. They usually do anyway.

When using the pepperflash player I've found the audio to be very choppy, as opposed to watching the same file with the standard flashplayer plug-in.

Try adding this argument when you start chrome:
Check and see if that works. Try a higher rate if needed.

Did the trick.
Thank you very much!
:hattip:

Awesome!!

Google just released a new version (27.0.1453.93) of Chrome. It looks like they have fixed the flash issue. At least for me it is fixed.

What a nice script, worked a treat on my 64 14.0 install. Will try my -current install tomorrow.:hattip:

Thanks.

No problem, glad you liked it. I have similar scripts for Opera and Firefox (the Firefox one is handy if you want to track the ESR version instead).

By the way I also have a variant of the Chrome script I am working on that allows you to install multiple Chromes side by side (Dev, Beta and Stable releases) and keep them all up to date. Thus allowing you to do comparative testing or try out new features without risk in breaking your stable setup. It already basically works but I would like to refine it a little more before I share it.

Yes, I read something about that (iirc). Count me in for testing.

edit: latest-chrome works fine in -current too.

@01micko: Ok, well if you want to test out a rough version then I provide a link to my multichrome script below. Before you try it I should explain a few things.

Firstly this version does not make Slackware packages. This is conscious decision because I want to be able to run multiple versions of Chrome on a variety of distros and do not want to have to create unique packaging scripts for each of the distros. However this is not such an issue as it might initially seem. The vast majority of Chrome is installed into /opt/google. The only things that go outside of this directory in the official packages are the repository setup files (in /etc), a symlink to the binary (in /usr/bin), the man page and desktop shortcuts + associated icons. All of those other things are therefore effectively optional. Everything you actually need to run Chrome stays in /opt/google. My script therefore retains only the essential components meaning that unistall is as easy as removing the relevant directory from /opt/google.

What my script therefore does is to check for the latest version of Chrome from the 'stable', 'beta' and 'unstable' channels and then downloads the relevant rpm package. Next it converts these rpm packages into simple tar archives. The conversion involves patching the install path so that the versions do not clash (and hence overwite) each other and then making a tar file from this. To install/upgrade you can simply untar these archives into the root (/) directory.

I should also clarify why patching is needed. Chrome expects to be installed into /opt/google/chrome. The binaries themselves have this full path hardcoded into them. My script therefore patches the binary such that a stable version looks for itself in /opt/google/chroms, a beta version looks for itself in /opt/google/chromb and an unstable version looks for itself in /opt/google/chromu. I then actually place Chrome into a directory named as follows /opt/google/google-chrome-channel-version-number.architecture, for example the current stable version for 64Bit would be installed in /opt/google/google-chrome-stable-27.0.1453.93-200836.x86_64/. Finally I drop a symlink in /opt/google named chroms (or chromb or chromu for beta and unstable respectively) pointing to this version. I do things this way so that it is possible to have multiple versions of Chrome from one channel installed in addition to multiple channels. If that sounds confusing, consider the following directory listing from my machine:

With the above setup if I run /opt/google/chroms/google-chrome it would start the 27.0.1453.93 stable version, whereas /opt/google/chromb/google-chrome would start the 28.0.1500.29 beta version and /opt/google/chromu/google-chrome would start the 29.0.1521.3 unstable version.

The trick with the symlinks means that should I decide to go back one stable version (e.g. to version 27.0.1453.93), I need only update the /opt/google/chroms accordingly.

Everything above deals with allowing multiple versions of Chrome to be installed side by side, however running them side by side also involves having to deal with the fact that they would all try to use the same profile. By default Chrome uses the directory ~/.config/google-chrome/ to store its profile. You can however override this and use any directory you like with the command line argument --user-data-dir=. To avoid having to constantly remember to use this you can setup the following bash aliases:

This means that you can just type chrome-stable to start the current stable, with the chrome-beta and chrome-unstable commands starting Chrome from their respective channels. Additionally the multichrome script as has a nice feature that will setup shortcuts for your desktop environment allowing you to start the various Chrome channels graphically without them clobbering each others profiles. By default running the multichrome script converts the relevant rpm to tar. However with the '-s' argument it will instead setup icons and shortcuts for any versions installed via this system. For example with my /opt/google setup as above I would get the following:

Should I remove the stable versions, running this command again would result in the following:

So with that all said, you can get the multichrome script from here. Just run it, pick which channel you wish to update and wait for the tar file to be created. To install simply extract into root, e.g.:

Thanks ruario! Works as advertised (mostly).

Only snag I hit was that when running multichrome.sh -s to create desktop files, /home/mick/.local/share/icons/hicolor didn't exist, a quick check in the script (edit: ah but of course there is) should fix that. Update: tried to reproduce by deleting /home/mick/.local/share/icons/ but couldn't, so may have been user error on first run.

@01micko: cools glad you got it working. One thing I forgot to mention. You can either continue to use my latest-chrome for stable and just use multichrome for the other two channels or you could just use multichrome for everything. However, if you use multichrome for stable and use the aliases I suggested or shortcuts produced by '-s' your stable profile will be in a different location and hence you will be starting again with a clean one.

P.S. This line should have ensured that directory was created:

Yes, thought of that and am going that way. At least then chrome is available (from menu) to all users if needed.
I saw that line, it was user error. :doh:

Yep, though if they do want to access the other versions from the menu's you can have them run multichrome -s.

Alternatively, an idea for a future update to this script would be to change how multichrome -s' works, such that if it is invoked by root it sets up desktop shortcuts for all users in /usr/local/share but when run by any other user it just uses ~/.local/share (as it does now) and sets up shortcuts only for them. What do you think, shall I do that?

One thought though, perhaps the script on initial run could check to see if chrome-stable (or possibly another version, either outdated or bleeding edge and anything in between) is installed either by SlackBuild , latestchrome or other means and if so ask if admin wants to remove that or leave. Or, perhaps not, admin should know what's on their system and make appropriate choices.


Entirely depends on your time and motivation. IMHO, the likelihood of this being implemented in a real multiuser (production?) situation is low as it is really for developers/testers, so "as is" is just fine. :)

@01micko: Not sure if you are still using this but I did a couple of updates and moved it to GitHub yesterday:

https://gist.github.com/ruario/9673716

Word of warning however if you rerun "multichrome -s" I no longer insert --user-data-dir into the desktop files to force a distinct settings folder for each channel, because Google now does it themselves in the startup scripts. But they name the folders differently. So if you rerun "multichrome -s" with the new version you would be using different settings folders and hence it would appear as if you were starting from scratch.

You could probably just stick with the version of multichrome you have already got or if you don't care about losing profiles for test channels it doesn't matter. However if you do want to fix this these are the locations I used:

These are the locations Google themselves use:

Another change I made was to stop patching the main chrome binary as as it no longer has it path hard coded. I also changed the naming of the symlinks from:

to:

ruario thanks for the update.

I do still use multichrome occasionally for testing, usually when a new feature is announced. No problem about the user data dir, I treat it as disposable anyway.

Great that you have moved these handy scripts (yes noticed the others) to GitHub. I find GitHub a pleasant experience with a simple "pull" command updating all that is needed from a particular repository.

Regards.

It occurred to that with the changes that Google have made (no fixed directory location hardcoded in the binary), it is no longer necessary to perform a system wide install. Hence new options are possible, specifically a given Chrome version can now be stored in its own, user owned directory along with its settings (profile), thus making it entirely self contained. This in turn makes it easier to compare builds from the same channel.

I knocked up a quick script to test this (linked below). I will probably tweak it further in the future to automate downloading the latest builds from each channel, like the multichrome script. For now it can just unpack and configure a Chrome rpm you specify on the command line.

Anyway if you want to try: https://gist.github.com/ruario/9728785