Hello. In a 64-bit, openSUSE, Leap-15.3, Linux operating system, which is installed as a so-called “guest” in Virtual “Machine” (VM) in Oracle (Corporation) VM VirtualBox, which in turn is installed in my so-called “host,” Windows 10 Home Edition operating system, I have gratefully had success in the playing of a .mp4 (Moving or Motion Picture Experts Group, audio layer-4) file in vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 from the Packman repository https://ftp.gwdg.de/ on the Internet with the Linux kernel 5.3.18-59.27.1-default. But in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 I had only the audio signals and not the video signals in the playing of that video. And later in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 with the Linux kernel 5.3.18-59.37.2-default I attempted to open vlc-beta, or the Video Local Area Network (LAN) Client (VLC) multimedia player (VLC) by double-clicking on a desktop shortcut for it, but saw its main window only for a very brief period of time, accompanied probably a short time later with the message “Segmentation fault (core dumped)”; so I could not even attempt to play that .mp4 file normally with this version of vlc-beta when using its probably default, Qt interface. In my Windows-10 “host” operating system I installed VirtualBox 6.1.28r147628 (probably amd64 for a 64-bit version suitable for I suppose at least an Advanced Micro Devices central processing unit [cpu]) on October 23, 2021 and updated it to VirtualBox 6.1.30r148432 (amd64) on November 26, 2021. These dates can be compared to the dates of release from the Packman repository of three versions of vlc-beta which I have been using: October 28, 2021; November 4, 2021; and December 10, 2021.
I at least began the process of preparation toward having a .rpm (RedHat package manager) file “built” for my Leap-15.3 installation using downloaded source code for vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1 or 20211104.b9e50b090c-pm153.10.1.16.1.x86_64 and an rpmbuild… command, but failed in that effort due to “Failed build dependencies”. I started that kind of process also with vlc-beta-20211210.736213df13-pm153.17.1.x86_64 by starting to obtain some software packages missing in my Leap-15.3 installation. And that process for my Leap-15.3 installation not only required a list of some tens of software packages; but I discovered two other difficult factors: 1) The software package mentioned between the parentheses of a pkgconfig(…) “response” following an rpmbuild… command is sometimes different than the name of a software package I could obtain from an openSUSE or Packman online repository. And I don’t know for certain if I can even obtain from somewhere on the Internet the exact package “requested”. 2) But in a “user-friendly” way it might be that sometimes rpmbuild might “accept” packages with names similar, but not exactly the same as the names of the packages between the parentheses of pkgconfig(…) (For example, I installed libnfs13, which has a name slightly different from the name of the package libnfs required for the rpmbuild… command.). But if similar names would not be “accepted” by rpmbuild and I could not obtain the exact software packages requested, in that case I don’t know what I should do to “satisfy” the “rpmbuild” command.
Rather than try to find and obtain some tens of software packages required for the successful execution of an rpmbuild command using the downloaded source code for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, I read that it is possible to have such a .rpm file “built” online using the openSUSE Build Service of the Open Build Service (OBS, https://build.opensuse.org/ on the Internet). It seems to be reported that such “building” could ease the action of obtaining the software packages “required” by rpmbuild. But I have not fully learned how to use OBS or tried it to make a .rpm file. But even if I would be successful in somehow “building” such a .rpm file for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, it is possible that after installing the corresponding software package from it that that might not eliminate the segmentation faults I have encountered, especially if it would be a change in the vlc-beta source code which would be needed to eliminate such segmentation faults.
Although the .rpm installation file for version 20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 of the software package vlc-beta is probably unfortunately no longer available from http://packman.links2linux.de/package/vlc-beta or https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/Multimedia/x86_64/, fortunately I have the capability to restore my Leap-15.3 installation, including the installation of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 in it, from a previously written backup of the data on my Dell notebook computer’s internal hard-disk drive. For a period of time I was able to “lock” or protect that version of vlc-beta, which has worked well for me, from being updated to a newer version of vlc-beta, which thus far has not worked for me when using its Qt interface. However, considering the likely future updates to some software packages and the Linux kernel elsewhere in my Leap-15.3 installation, the arrangement of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 working well with a number of newer software packages might at some time in the future no longer be a mutually well-working arrangement for me. At least by the time of an upgrade from version 15.3 to version 15.4 of Leap on or after June 8, 2022 there could be a possible software mismatch, since according to http://packman.links2linux.de/package/vlc-beta the version vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 saved in my hard-disk drive’s backup data is reported to be suitable for a Leap-15.3 installation. So I have been attempting to find some way to make the version of vlc-beta released to the public on December 6, 2021, namely vlc-beta-20211210.736213df13-pm153.17.1.x86_64, work in a Qt interface in my Leap-15.3 installation. And the hope would be that after having made it to work that way in my Leap-15.3 installation that making later versions of vlc-beta to work in that way in my Leap-15.3 installation might be easier than now for vlc-beta-20211210.736213df13-pm153.17.1.x86_64.
I have been able to play a .mp4 file in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 using a command of the form “vlc -I dummy FILE_NAME.mp4” in a directory containing the file with a name of the form FILE_NAME.mp4. Otherwise entering the command “vlc” or “gdb vlc”, using the GNU’s Not Unix (GNU) debugger (gdb), in the directory /usr/bin resulted in the main window for vlc-beta opening, but with most of it transparent; then very soon afterward I received the message “Segmentation fault (core dumped)”. Those same two things occurred after I entered the command “vlc -I qt” in the directory /usr/bin. So my current problem is associated with Qt and the main window of vlc-beta, not the so-called “dummy interface” of vlc-beta. If the “menu” items and/or software controls on vlc-beta’s main window are considered plugins, then it appears to me that the problem is in displaying those items on vlc-beta’s main window. But in vlc-beta’s code and its output and on the Internet this main window is called the main interface; or Qt has been called the default interface for VLC on https://wiki.videolan.org/Qt_Interface/. In some of my past executions of “vlc” I have seen the output “ReferenceError: mainInterface is not defined,” but not on December 15, 2021, after having installed lots of software packages relating to the display protocol Wayland (https://www.maketecheasier.com/what-is-wayland/) and/or the widget “tool kit” Qt, version 5, for making graphical user interfaces and applications suitable for use in various computer operating systems, which are otherwise called platforms https://en.wikipedia.org/wiki/Qt_(software)].
Here is a listing of my virtual computer’s “hardware” in my Leap-15.3 installation in VirtualBox on December 15, 2021.
newbie@linux-hdi0:/usr/bin> inxi -G
Graphics:
Device-1: InnoTek Systemberatung VirtualBox Graphics Adapter
driver: vboxvideo v: 6.1.30 r148432
Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa
resolution: 1308x600
OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 20.2.4
newbie@linux-hdi0:/usr/bin>
And here is a list of the online repositories to which I currently have set up access in my Leap-15.3 installation when it is online. To obtain this list I may have entered the command
zypper repos
as a “root” user.
linux-hdi0:/usr/bin # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.
# | Alias | Name | Enabled | GPG Check | Refresh
---+----------------------------------+---------------------------------------------------------------------------------------------+---------+-----------+--------
1 | http-ftp.gwdg.de-2f96c871 | Packman Repository | Yes | (r ) Yes | Yes
2 | http-opensuse-guide.org-46cfd2d4 | libdvdcss repository | Yes | (r ) Yes | Yes
3 | openSUSE-Leap-15.3-1 | openSUSE-Leap-15.3-1 | Yes | (r ) Yes | No
4 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ----
5 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | Yes
6 | repo-debug | Debug Repository | No | ---- | ----
7 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ----
8 | repo-debug-update | Update Repository (Debug) | No | ---- | ----
9 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ----
10 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes
11 | repo-oss | Main Repository | Yes | (r ) Yes | Yes
12 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ----
13 | repo-sle-update | Update repository with updates from SUSE Linux Enterprise 15 | Yes | (r ) Yes | Yes
14 | repo-source | Source Repository | No | ---- | ----
15 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes
16 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes
linux-hdi0:/usr/bin #
With the help of a good teaching video on how to use the GNU’s Not Unix (GNU) debugger (gdb) on https://www.youtube.com/watch?v=bWH-nL7v5F4, by Doctor Chris Bourke of the University of Nebraska in Lincoln, Nebraska, The United States of America, I was able to proceed, statement-by-statement, in some of vlc-beta’s computer code with those statements looking to me like C-language statements, but more often looking like C-programming-language statements if I omitted the command within gdb of “layout next”; otherwise after entering the command “layout next” on December 14, 2021 and probably entering
gdb vlc
and
run
eventually I saw a number of lines in an upper panel each containing a hexadecimal address, a short word or phrase like “mov”, “test”, “call”, “je”, et cetera (Maybe it was assembly language??? But perhaps things looked strange instead of like C-language statements because I was missing some installed debugging packages, as the output below seemed to indicate.) Below the input “n” stands for “next” to instruct the computer program to go to the next statement to execute it in the computer code. So below are the results of some exploring of mine with vlc-beta on December 15, 2021 using the gdb. Despite “vlc” instead of vlc-beta appearing in the first command below, it is for vlc-beta. And I removed all of the VLC computer software and the VLC-based computer program caffeine from openSUSE, except, as I discovered later, the directory /home/newbie/.config/vlc, in my Leap-15.3 installation. Instead I have vlc-beta computer software from the Packman online repository installed in my Leap-15.3 installation.