v18 SSL Certificates Issues
#46
@JohnPlayerSpecial can you try the last nightly before PR #13647 was merged? If it works there I guess we'll have to find the exact place where it doesn't treat the protocol options appropriately.
Reply
#47
(2018-06-12, 21:21)yol Wrote: @JohnPlayerSpecial can you try the last nightly before PR #13647 was merged? If it works there I guess we'll have to find the exact place where it doesn't treat the protocol options appropriately.
 That was on on 19 Apr (https://github.com/xbmc/xbmc/pull/13647 ?) - in http://mirrors.kodi.tv/nightlies/windows/win64/master/ the oldest one is KodiSetup-20180501-3a989eee-master-x64.exe (compiled 2018-May-02 03:57), so where can I find older ones?

But I made some tests with another webdavs cloud, that works without -verifypeer=false and marked out other problems (far away from the ones I discribed about cleaning library initially here https://forum.kodi.tv/showthread.php?tid...pid2742328). Btw I think it would be more efficient if team-members test this on an own cloud instead of this indirect way because there seemed to be several problems. But I will try to explain:

First: KodiSetup-20180501-3a989eee-master-x64.exe (compiled 2018-May-02 03:57):
- Adding a webdavs HTTPS source and updating your library -> all movies (8 in my test) were added
- Test 1) Delete a file from library manually -> 7 movies remain in the library. Updating your library again -> 8 movies in the library again. Correct so far.
- Test 2) Change (or delete) a movie-file direct in webdavs (I changed movie1.mkv to movie.m), clean library -> 7 movies remain in library. Change name to movie1.mkv again. Updating your library again -> Still only 7 movies in library! No chance to re-adding it via update.

Second: KodiSetup-20180504-74ebeb38-master-x64.exe (compiled 2018-May-05 04:01):
Already Test 1 fails -> manually delete a movie from library and updating your library again does not re-add the movie.

If you write me a PN, I can give you login information and password for my test-cloud (common magentacloud in this case) because, as I wrote, I suppose there's a little bit more broken as I can show indirect via log files or explain in my own words.

____________
PS (don't know if it is important but..) I set local information only and my folderstucture on webdavs is:
Movie1 (1997)
->
   movie1.mkv
   movie1.nfo
   movie1-fanart.jpg
   movie1-poster.jpg
Movie2 (2003)
->
   movie2.mkv
   movie2.nfo
   movie2-fanart.jpg
   movie2-poster.jpg
Movie3 (1990)
->
   movie3.mkv
   movie3.nfo
   movie3-fanart.jpg
   movie3-poster.jpg
Movie4 (2000)
->
   movie4.mkv
   movie4.nfo
   movie4-fanart.jpg
   movie4-poster.jpg
Movie5 (2017)
->
   movie5.mkv
   movie5.nfo
   movie5-fanart.jpg
   movie5-poster.jpg
...
(each movie in an own folder)
Reply
#48
OK if it's broken anyway without verifypeer I think we can focus on these bugs for now and see if the SSL-related stuff gets fixed as a by-product.

Did you by any chance test this already on a local file source? Otherwise I'll just do that myself to narrow it down (whether it's a DAV problem or more general).
Reply
#49
Also, it seems really strange that something changed between 20180501 and 20180504... Can you double-check that it wasn't just a fluke? I looked at the changes between the revisions and nothing really looked like it could cause this - of course that does not mean anything :-) If there really is a reproducable difference that would narrow it down incredibly.

Thanks a lot for your patience and testing!
Reply
#50
(2018-06-12, 22:30)yol Wrote: OK if it's broken anyway without verifypeer I think we can focus on these bugs for now and see if the SSL-related stuff gets fixed as a by-product.

Did you by any chance test this already on a local file source? Otherwise I'll just do that myself to narrow it down (whether it's a DAV problem or more general).
 I did not checked Test1) again, but Test2) also fails on a local file source. I tested it just now with KodiSetup-20180504-74ebeb38-master-x64.exe (compiled 2018-May-05 04:01) Here is my Testmovie-folder with dummyfiles: https://www80.zippyshare.com/v/dxhUa1SA/file.html
Reply
#51
The Test1) seems not to be a problem for local file source. But over webdavs it's not possible to re-add a movie via update library when deleted it manually before KodiSetup-20180504-74ebeb38-master-x64.exe (compiled 2018-May-05 04:01): log (removed)

(I dont know if its because the mkv-files are 1kilobyte dummies?)
After downgrade to KodiSetup-20180501-3a989eee-master-x64.exe (compiled 2018-May-02 03:57) movies could added again. Deleting from library and re-updating works. Only problems with Test1 which also exist on local storaged stuff.
Reply
#52
(2018-06-12, 23:22)JohnPlayerSpecial Wrote: (I dont know if its because the mkv-files are 1kilobyte dummies?)
It's not. I changed all dummyfiles to small videos https://www78.zippyshare.com/v/eUQazMHT/file.html - re-adding still is impossible after deleting once23:13:15.982 T:214444 WARNING: Skipping item 'davs://USERNAMETongue[email protected]:443/Shutter%20Island%20(2010)/Shutter%20Island.mkv' with '.nomedia' file in parent directory, it won't be added to the library.
Reply
#53
(2018-06-12, 23:40)JohnPlayerSpecial Wrote: It's not. I changed all dummyfiles to small videos https://www78.zippyshare.com/v/eUQazMHT/file.html - re-adding still is impossible after deleting once23:13:15.982 T:214444 WARNING: Skipping item 'davs://USERNAMETongue[email protected]:443/Shutter%20Island%20(2010)/Shutter%20Island.mkv' with '.nomedia' file in parent directory, it won't be added to the library.

Seems it thinks there's a .nomedia file even though it's getting a 404. Finally some code to investigate :-)
Reply
#54
(2018-06-13, 00:04)yol Wrote:
(2018-06-12, 23:40)JohnPlayerSpecial Wrote: It's not. I changed all dummyfiles to small videos https://www78.zippyshare.com/v/eUQazMHT/file.html - re-adding still is impossible after deleting once23:13:15.982 T:214444 WARNING: Skipping item 'davs://USERNAMETongue[email protected]:443/Shutter%20Island%20(2010)/Shutter%20Island.mkv' with '.nomedia' file in parent directory, it won't be added to the library.

Seems it thinks there's a .nomedia file even though it's getting a 404. Finally some code to investigate :-)  
 Maybe a good news: It does not seemd to be a magentacloud specific thing as I get the same error message with my webdavs on my nas with your KodiSetup-20180611-604e2923-PR14016-merge-x64.exe
00:16:20.461 T:215244 WARNING: Skipping item 'davs://USERNAMETongue[email protected]:5003/webdav/nas2/SD/Wei%c3%9ft%20was%20geil%20w%c3%a4r..!%20(2007)/|verifypeer=false' with '.nomedia' file in parent directory, it won't be added to the library.
Reply
#55
Any News about fixing the two problems yet?
Reply
#56
Hi,

the .nomedia problem should be gone with https://github.com/xbmc/xbmc/pull/14038 - it should have only been there when enabling CURL component logging. It also explains the difference you have seen between the May 02 and May 05 versions, since the problematic PR was merged between those dates.

I have however identified some more problems:
  • Somehow the path of the source gets registered twice in the database, one time with verifypeer=false and one time without, and both are used for different purposes. I still need to find out why we get the source twice in the first place, so it could be difficult.
  • When deleting content from the library with "Clean library", the content hash for the folders is not reset. This basically means that if the directory looks the same between an library update you do before and after the cleaning (for example because you copied the files you deleted back), it will not be re-scanned even though it should (since content was deleted that would have to be re-added). This still needs to be fixed and should not be complicated, but first the problem above needs to be solved.
  • .nomedia is sometimes checked on files and not on directories; fixed by https://github.com/xbmc/xbmc/pull/14076
If I remember correctly your initial problem of having all files disappear from library on cleanup is fixed, right? I'll be away for a few days so the remaining fixes might need some time.
Reply
#57
(2018-06-18, 17:31)yol Wrote: Hi,

the .nomedia problem should be gone with https://github.com/xbmc/xbmc/pull/14038 - it should have only been there when enabling CURL component logging. It also explains the difference you have seen between the May 02 and May 05 versions, since the problematic PR was merged between those dates.

I have however identified some more problems:
  • Somehow the path of the source gets registered twice in the database, one time with verifypeer=false and one time without, and both are used for different purposes. I still need to find out why we get the source twice in the first place, so it could be difficult.
  • When deleting content from the library with "Clean library", the content hash for the folders is not reset. This basically means that if the directory looks the same between an library update you do before and after the cleaning (for example because you copied the files you deleted back), it will not be re-scanned even though it should (since content was deleted that would have to be re-added). This still needs to be fixed and should not be complicated, but first the problem above needs to be solved.
  • .nomedia is sometimes checked on files and not on directories; fixed by https://github.com/xbmc/xbmc/pull/14076
If I remember correctly your initial problem of having all files disappear from library on cleanup is fixed, right? I'll be away for a few days so the remaining fixes might need some time. 
Thanks for Info so far! First problem sounds not trivial..

The library is generally something basic to me (also for other users I think^^) that I absolutely need working for leia - because I use Kodi on Odroid at home and also mobile with an AML Box - both systems are connected to nas (through verifypeer=false since SSL changes). This is why I will go on testing the windows-nightlies and also test those procedures (cleaning + updatating library, file-changes on source..) until it workes again.

Yes, the initial problem (verifypeer=false-source "unaivalable" when cleaning) was seemingly solved by https://github.com/xbmc/xbmc/pull/14016 respectively this testbuild http://mirrors.kodi.tv/test-builds/windo...ge-x64.exe your provided. But I will test this and also https://github.com/xbmc/xbmc/pull/14076 again, when it's merged in next nightly or you provide a link to a new testbuild and give feedback.

For the remaining fixes please keep me up to date in this thread as there is news about. Thanks for your support!
Reply
#58
(2018-06-18, 17:31)yol Wrote:  
  • When deleting content from the library with "Clean library", the content hash for the folders is not reset. This basically means that if the directory looks the same between an library update you do before and after the cleaning (for example because you copied the files you deleted back), it will not be re-scanned even though it should (since content was deleted that would have to be re-added). This still needs to be fixed and should not be complicated, but first the problem above needs to be solved.
 I tested KodiSetup-20180629-254e7f9c-master-x64.exe today and this problem is left: After deleting a folder/moviefile from webdav-source and doing "clean library" kodi deletes movie from library - perfect. But if you re-add this folder/file to the webdav-source re-adding via "update library" does not rescan it to library.

Problems in connection with -verifypeer=false I will not test atm/anymore. I added my cert to installation to avoid these additional problems.
Reply
#59
Hey guys, I can not open ftps source too with forced ssl settings in vsftpd server:
Quote:allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=/etc/vsftpd/ssl/vsftpd.pem
KodiSetup-20180919-2c44473e-master-x64.exe
Logfile Pastebin
source.xml
Quote:        <source>
            <name>TEST</name>
            <path pathversion="1">ftp://user:[email protected]:port/|AUTH=TLS|verifypeer=false</path>
            <allowsharing>true</allowsharing>
      </source>
  I tried many different things: Adding ftp cert and playing around with source path but its only connecting if I set force_local_data_ssl=NO & force_local_logins_ssl=NO
My sources.xml was working very well in Kodi 17

---
ps: What is this "folder.jpg" I dont have this on server.
RROR: CCurlFile::Exists - Failed: Login denied(67) for ftp://USERNAME:[email protected]:xxportxx/folder.jpg|AUTH=TLS|verifypeer=false
Reply
#60
@ködi-zömbie

You've got add-ons in the log which violate our piracy policy (wiki).

The forum moderators have determined that banned addons (wiki) are present on your system. To receive assistance here, these banned items must be removed. If a clean log is not submitted within 3 days, then the relevant post(s) will be removed after this time.
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply

Logout Mark Read Team Forum Stats Members Help
SSL Certificates Issues2