My general computer-software setup is
A) a so-called “host” operating system of 64-bit Windows 10 Home Edition,
B) Oracle Corporation VM (Virtual “Machine”) VirtualBox, hereafter referred to as “VirtualBox,” as an installed application within that Windows operating system, and
C) a so-called “guest” operating system of 64-bit openSUSE, Leap-15.5, Linux operating system.
On May 4, 2024 some major computer-software changes I made were
-
to replace VirtualBox 7.0.14r… with VirtualBox 7.0.18r162988 (Qt5.15.2) and
-
to install or make changes concerning 49 software packages in my Leap-15.5 operating system. Among those installed software packages was an installation of the software package vlc-beta.
But afterward a strange thing occurred when I tried to open a .mp4 (Motion Picture Experts Group [MPEG], Audio Layer 4) file in VideoLAN (Video Local Area Network) Client (VLC) media player.–Instead seeing the video signal and hearing the music from that .mp4 file being played in VLC media player, I eventually saw a login screen for me to input my regular-user password to enter my Leap-15.5, so-called “desktop” screen! I tried to open that .mp4 file in two different ways: a) by initially clicking on a blue rectangle with VLC media player’s main “window” or b) by clicking a vertically aligned set of three dots on the right-hand side of that main “window” and then selecting “Media”, “Open File…” I also missed seeing the neat-looking “menu” items across the top of VLC media player’s main “window.”
I began to investigate my situation concerning installed VLC-related software packages in my installation of Leap 15.5. I think I have had things set up within Yet another Software Tool (YaST) or Yet another Software Tool 2 (YaST2) so that codecs (code-decodes) are preferred from a Packman repository over a Leap-15.5 repository. Via YaST or YaST2 I could see that there was a version disparity among those installed, vlc-related software packages, as shown in the following table.
| Installed Software Package | Version |
|---|---|
| vlc-beta | 20240501.0e39c (or less likely e) 9595-150500.18.pm.1 |
| libvlccore9 | 3.0.20-150500.2.5.pm.2 |
| libvlc5 | 3.0.20-150500.2.5.pm.2 |
I also paid attention to the vendors supplying some installed, vlc-related software packages. To make both the versions and vendors supplying my installed, vlc-related software packages be the same, I set up the following changes to be made before clicking on an “Accept” software “button:”
to delete vlc-beta and
to install vlc 3.0.20-150500.2.5.pm.2 from the vendor http://packman.links2linux.de.
But in addition I could see that the following software packages would also be installed of probably the latter above change:
vlc-codecs-gstreamer,
vlc-nox,
vlc-qt. and
vlc-vdpau.
On a “Versions” tab I insisted between the typically pairs of choices that the supplying vendor would be http://packman.links2linux.de or else Packman and that the version would be 3.0.20-150500.2.5.pm.2 for each of those software packages to match such data with the corresponding data for the software package vlc that I was to install. After clicking on the “Accept” software “button” I accepted two more changes which I was informed would resolve some software-dependency issues.
After those changes were made, gratefully VLC media player in my Leap-15.5 installation returned to normal operation in both the opening and playing of the .mp4 file and in having a normal horizontal array of “menu” items across the top of VLC media player’s main “window!”
I suspect that it may have been the installation of vlc-beta in my Leap-15.5 installation which caused my trouble in using VLC media player. I then set up the following software packages to be “Taboo” to prevent them from being installed in future updates of my Leap-15.5, computer-software packages:
vlc-beta,
vlc-beta-debuginfo, and
vlc-beta-debugsource.
I suppose that in general the word “beta” in the name of a software package might indicate a version of a software package which may not have been as thoroughly tested as a similarly named software package without “beta” in its name. And logically that could make name-including-beta software packages more likely to have problems than name-not-including-beta software packages. Unless someone can advise me otherwise, this is my way of hoping to avoid some potential future trouble with computer software. I wrote “trouble” here because, at the beginning after my encountering software trouble, it may not be easy for me to determine the cause of such computer-software trouble when I did not write the computer code for a software package, even if that computer code is open-source and publicly available computer code.
However, I think I am still maintaining a preference of the Packman repository over an openSUSE repository for I think software packages of the same names. From at least SDB:System upgrade - openSUSE Wiki on the Internet I learned that I should leave the Packman repository as active during an upgrade of an openSUSE Linux operating system. Thinking deeply about this matter, I guess that such advice would make sense when performing such an upgrade while one’s computer is connected to the Internet because I would not expect the Packman repository’s software packages to be on a Recordable Digital Versatile or Video Disc (DVD-R) for a new version of an openSUSE, Linux operating system when performing an offline upgrade using Leap-15.6 installation file written onto such a DVD-R. So this reasoning could mean that I should perform my upgrade from Leap 15.5 to Leap 15.6 while my portable computer can be online for several hours of time on or after June 12, 2024, the date according to openSUSE Leap 15.6 Is Now Available for Public Beta Testing with GNOME 45 - 9to5Linux on the Internet when Leap 15.6, not in a “beta” testing mode, is expected to be publicly released.