Description of problem: Our Minitube version is outdated. Minitube 4.0 been released in August 2024. Our Minitube version can't reproduce a lot of videos that I search. Version-Release number of selected component (if applicable): Minitube 3.9.3 in Mageia 9 How reproducible: Install Minitube and search some videos. Steps to Reproduce: 1. Install Minitube 2. Search some videos and play. 3. It can see that the list is jumping to next video without reproduce the videos.
Version: 9 => CauldronAssignee: bugsquad => j.alberto.vc
Lot of changes and some new dependencies This will take a time and can't be updated in mageia 9
Leave to all packagers, I'll keep trying but looks that require more experimented packagers
Assignee: j.alberto.vc => pkg-bugs
Whiteboard: (none) => MGA9TOOAssignee: pkg-bugs => j.alberto.vc
I get it build with qt5 latter I'll test with qt6 in cauldron
RPM: minitube-4.0-1.mga9 SRPM minitube-4.0-1.mga9
Version: Cauldron => 9Assignee: j.alberto.vc => qa-bugsWhiteboard: MGA9TOO => (none)
LC_ALL=C urpmi minitube installing minitube-4.0-1.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################## 1/1: minitube ################################################################################################## In my opinion, works badly, if you select Play manually some videos not play and start to skip videos in the result list Not like
Agree with katnatek, I found no way to select one of the list of videos and play that specific one. And BTW, I got this at the CLI: $ minitube [unknown] Wayland does not support QWindow::requestActivate() [unknown] Wayland does not support QWindow::requestActivate() Not giving much confidence..... And tried the current 3.9 version, behaves exactly the same, so no regression. IMHO, letting this update go wouldn't do any harm - any good either.
CC: (none) => herman.viaene
CC: (none) => yvesbrungardSource RPM: Minitube => minitube
I have installed in mga x64 in Netbook Asus eeepc. Works fine for me, same that 3.9.3, although the new version can't reproduce some videos either.
mga9, x64 Played with minitube but could find no fault with it apart from no way to enable subtitles. Updated and tried it out again, choosing the last film viewed. Tried transferring to a browser and noted that the playback had started at the point where I had left it in the pre-update test. That also allowed the selection of subtitles if they were available. Note that the application runs in 'restricted mode'. Tried a PayPal contribution and restarted but still in restricted mode. Also tried to set up a subscription but could not find the * button. It is possible that the application is still so much a work in progress that enforcement of restricted mode is necessary. Have not yet found anything which minitube fails to play. The search function works and the snapshot by key F9, saving snapshots in the Pictures directory. $ inxi -G Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Lucienne driver: amdgpu v: kernel Device-2: PCTV Systems tripleStick 292e driver: em28xx type: USB Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: amdgpu,v4l dri: radeonsi gpu: amdgpu resolution: 2560x1440~60Hz API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.6 vendor: amd mesa v: 25.0.7 renderer: AMD Radeon Graphics (radeonsi renoir ACO DRM 3.54 6.6.93-1.mga9) API: Vulkan v: 1.3.231 drivers: radv,llvmpipe surfaces: xcb,xlib
CC: (none) => tarazed25
In reply to Len Lawrence in comment #8: Spoke too soon. The earlier fault reported by others seems to have returned. Select a category for search and a list is presented but the cursor moves down the list of its own accord which makes it impossible to choose a particular title. Tried crashing out and restarting with a different search criterion but the moving cursor fault is still there. Running this from a terminal allows the user to see that each selection comes up as '[unknown] "Failed to open https://....."' e.g. [unknown] "Failed to open https://rr1---sn-8pgbpohxqp5-ac5e7.googlevideo.com/videoplayback?expire=1751869050&ei=GhJraLT7CLOIvdIPj-WXuAk&ip=82.31.104.191&id=o-ADKCU4rw4XM4VNVqHQlwiP0XxnA9RUs0tCQx-PRboEF4&itag=137&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&met=1751847450%2C&mh=01&mm=31%2C29&mn=sn-8pgbpohxqp5-ac5e7%2Csn-aigzrnz7&ms=au%2Crdu&mv=m&mvi=1&pl=22&rms=au%2Cau&initcwndbps=4446250&bui=AY1jyLOWYSSVtZGvMtqFYnViHB2aWZ618ggCt_89LfMPs1_SRAk3PSqv6fev8S2nzj720aUHmdIu22SG&spc=l3OVKUV060jXJoTpkNKyrItdsDuRbaxh20QsxS3LLjGJUjqBLau2OhlbqWs4QA&vprv=1&svpuc=1&mime=video%2Fmp4&rqh=1&gir=yes&clen=1876705030&dur=4328.333&lmt=1747633198899104&mt=1751846934&fvip=5&keepalive=yes&fexp=51476175&c=IOS&txp=5532534&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJfQdSswRAIgQcg4W8IqJfKPZl57Dd3iYJcRTscbI6ZJGWZpicGnMGwCIAL484q9qNtBcC2j8sR5hSY0IlLWoOH_e_8iaa3j_u2O&lsparams=met%2Cmh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Crms%2Cinitcwndbps&lsig=APaTxxMwRgIhAMqOc350R7RLvOmcjGTEBvaKJlRUqoSnbX7FZn8L5voRAiEAyqQAX92pU5FbMwnByrrslbDM7MZa_DSuGH0Ep0kQymA%3D&pot=MpcBup81gkaNiE26pLh1Ah5IRI2x_YcMK1_L1CulKCp5Bp3a4udaeKjHnm1w4aAtmrVwxN0kTL1KV0iAjsWC1QfRMsj80aD04Ul6zKnTOwfh7IYRQ0RlG87GWyM9wetc3ORKCKyh2OPbY8hzjxWBXPNEOqVsvysbpbUKfdO_8PwkHyBcmMIMnks2ax3oGEHSp86t96LIBZWLVA%3D%3D.\n" Looks like some switch in the program gets flipped by the first run and scuppers subsequent operations. Tried $ rm -f '~/.local/share/Flavio Tordini/Minitube/minitube.db' and restarted but the fault continued to manifest and the old search terms had been remembered but the local Minitube directory now contains only functions.js. Removed that and was able to restart the application and play a video but changing the search term after stopping the first video caused the moving cursor fault to return. Note that the user's Minitube directory remains empty. However, the user's .config directory also has a "Flavio Tordini" directory containing Minitube.conf. Edited that to empty the recentKeywords= entry and set manualplay=true. That cleared the runaway cursor problem - back to square one. No problems changing search value and selecting another video, stopping and starting and choosing a new film. Note that the interface now displays a caption at the bottom RH corner of the viewer saying "Manually start playing". If the clip is stopped manually the list disappears and needs to be reloaded by specifying the search pattern again (by clicking on one of the displayed values). So, it looks like it is well-behaved with that one change to the configuration file but the runaway cursor fault still needs to be addressed. Not OK.
In reply to Len Lawrence in comment #9: Shall have a look at the advisory later today.
(In reply to Len Lawrence from comment #10) > In reply to Len Lawrence in comment #9: > > Shall have a look at the advisory later today. Please don't upload advisory, let this in testing, I believe this should be returned to all packagers
(In reply to katnatek from comment #11) OK - shall leave it.
Return to maintainer
Assignee: qa-bugs => cooker
How is this issue progressing in Caldero? I see that version 4 is still in testing in Mageia 9, but with the same error.
As the maintainer, I remember giving up on this after problems finding a valid Youtube API key from Mageia to use. Minitube needs a valid API key to work.
Then we can close this bug, and vote to obsolete the application and get it out of maintenance of Mageia ....
Blocks: (none) => 32127
Added to Bug 32127 - [TRACKER] Packages that need to be obsoleted for Mageia 10 release
CC: (none) => fri
(In reply to Jose Manuel López from comment #16) > Then we can close this bug, and vote to obsolete the application and get it > out of maintenance of Mageia .... It doesn't mean we can't fix it. I know Mageia has an API key, I just down know which API key we can use.
I don't know if the problem is the API for the matter of continuous continuous reproduction.
(In reply to Johnny A. Solbu from comment #18) > (In reply to Jose Manuel López from comment #16) > > Then we can close this bug, and vote to obsolete the application and get it > > out of maintenance of Mageia .... > > It doesn't mean we can't fix it. > I know Mageia has an API key, I just down know which API key we can use. As I can see we are using a valid api key as is the same used to build chromium-browser-stable